Control y Auditoría de Tecnologías de La Información

Página 1
Tecnologías de la información
Control y Auditoria
Página 3
2
Control y Auditoria
Quinta edición
Ángel R. Otero
Página 4
Prensa CRC
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Ratón, FL 33487-2742
© 2019 por Taylor & Francis Group, LLC

CRC Press es una impresión de Taylor & Francis Group
Sin reclamo de obras originales del gobierno de EE.
Impreso en papel sin ácido
Libro estándar internacional número-13: 978-1-4987-5228-2 (tapa dura)
Este libro contiene información obtenida de fuentes auténticas y de gran prestigio. Se han realizado esfuerzos razonables
hecho para publicar datos e información confiables, pero el autor y el editor no pueden asumir la responsabilidad de la
validez de todos los materiales o las consecuencias de su uso. Los autores y editores han intentado rastrear el
los titulares de los derechos de autor de todo el material reproducido en esta publicación y pida disculpas a los titulares de los
publicar en este formulario no se ha obtenido. Si no se ha reconocido algún material con derechos de autor, escriba y deje
nosotros lo sabemos para que podamos rectificar en cualquier reimpresión futura.
Excepto según lo permitido por la ley de derechos de autor de EE. UU., Ninguna parte de este libro puede ser reimpresa, reproducida, transmitida o
utilizado en cualquier forma por cualquier medio electrónico, mecánico o de otro tipo, ahora conocido o inventado en el futuro, incluida la fotografía
para copiar, microfilmar y grabar, o en cualquier sistema de almacenamiento o recuperación de información, sin permiso por escrito
de los editores.
Para obtener permiso para fotocopiar o utilizar material electrónico de este trabajo, acceda a www. copyright.com (http: //
www.copyright.com/) o póngase en contacto con Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA
01923, 978-750-8400. CCC es una organización sin fines de lucro que proporciona licencias y registros para una variedad de usuarios.
Para las organizaciones a las que la CCC les ha otorgado una licencia de fotocopia, se ha establecido un sistema de pago separado
arreglado.
Aviso de marca comercial : los nombres de productos o corporativos pueden ser marcas comerciales o marcas comerciales registradas, y se utilizan solo para
identificación y explicación sin intención de infringir.
Visite el sitio web de Taylor & Francis en

http://www.taylorandfrancis.com
y el sitio web de CRC Press en

https://www.crcpress.com
Página 5
Le dedico este libro a mi esposa, Ghia, mi hija Elizabeth y mi

hijos, Leonardo y Giancarlo. También dedico este libro a mis padres,
Angel y Lydia, y mis hermanos Luis Daniel y Carlos.
Página 7
6
Contenido
Prefacio ................................................. .................................................. ................................. xvii

Agradecimientos ................................................. .................................................. .............. xxiii
Autor ................................................. .................................................. .................................. xxv
SECCIÓN I FUNDAMENTOS PARA LA AUDITORÍA DE TI

1 Entorno de tecnología de la información y auditoría de TI ........................................... ........ 3
Entorno de TI ................................................ .................................................. ............... 3
Planificación de recursos empresariales (ERP) ............................................ ................................. 4
Computación en la nube ................................................ .................................................. ....... 5
Gestión de dispositivos móviles (MDM) ............................................ ............................... 6
Otros sistemas tecnológicos que impactan el entorno de TI ... 6
Entorno de TI como parte de la estrategia de la organización .......................................... ......... 7
La profesión de auditor ............................................... .................................................. .... 7
Auditoría financiera ................................................ .................................................. ...... 9
Funciones de auditoría interna versus externa ............................................. ............................. 10
Función de auditoría interna ............................................... ................................................ 10
Función de auditoría externa ............................................... ............................................... 11
¿Qué es la auditoría de TI? .................................................. .................................................. ... 11
Tendencias de auditoría de TI ............................................... .................................................. .......... 13
Aseguramiento de información ................................................ .................................................15
Necesidad de auditoría de TI .............................................. .................................................. .............dieciséis
Gobierno de TI ................................................ .................................................. ........... 18
Papel del auditor de TI ............................................. .................................................. ....... 19
Auditor de TI como consejero .............................................. ................................................. 19
Auditor de TI como socio de la alta dirección ........................................... ................... 20
Auditor de TI como investigador .............................................. ............................................. 20
Auditoría de TI: la profesión ............................................. .................................................. .... 21
Un cuerpo común de conocimientos ............................................. ..................................... 21
Certificación ................................................. .................................................. ............. 22
Educación continua ................................................ ................................................ 22
Asociaciones profesionales y estándares éticos ............................................. ............. 23
Currículo educativo ................................................ ................................................. 24
Perfil del auditor de TI: experiencia y habilidades ........................................... ............................... 25
Oportunidades profesionales ................................................ .................................................. ..... 26
vii
Página 8
viii ◾ Contenido
Empresas de Contaduría Pública ............................................... .............................................. 26

Industria privada ................................................ .................................................. ......... 26
Empresas de consultoría de gestión ............................................... .................................... 26
Gobierno ................................................. .................................................. ............. 27
Conclusión ................................................. .................................................. .................... 27
Preguntas de revisión ................................................ .................................................. .......... 28
Ejercicios ................................................. .................................................. ....................... 28
Otras lecturas ................................................ .................................................. ............ 29
2 Legislación relevante para las tecnologías de la información ............................................ ........... 31

Delitos informáticos y ciberataques .............................................. ............................................... 31
Legislación Federal de Integridad Financiera — Ley Sarbanes-Oxley de 2002 ............................. 35
PCAOB ................................................. .................................................. .................... 36
Normas de independencia del auditor y normas de gobierno corporativo ........................... 37
Aumento de las sanciones penales por infracciones de las leyes de valores ................................... 38
Legislación federal de seguridad ............................................... .............................................. 38
Ley de Fraude y Abuso Informático de 1984 ........................................... .......................... 39
Ley de seguridad informática de 1987 ............................................. ...................................... 39
Ley de Seguridad Nacional de 2002 ............................................. ..................................... 40
Normas de seguridad de datos de la industria de tarjetas de pago de 2004 .......................................... ..41
Ley Federal de Administración de Seguridad de la Información de 2002 ........................................... ... 41
Leyes de firma electrónica — Ley uniforme de transacciones electrónicas de 1999 y
Ley de firmas electrónicas en el comercio mundial y nacional de 2000 ............... 42
Legislación de privacidad ................................................ .................................................. ......... 42
Ley de Privacidad de 1974 .............................................. .................................................. ..... 43
Ley de Privacidad de Comunicaciones Electrónicas de 1986 ............................................ ............ 43
Ley de Decencia en las Comunicaciones de 1996 ............................................. .......................... 44
Ley de Protección de la Privacidad Infantil en Línea de 1998 ........................................... ........... 44
Ley de Portabilidad y Responsabilidad del Seguro Médico de 1996 ..................................... 44
La tecnología de la información sanitaria para la salud económica y clínica de 2009 ... 45
Ley Gramm – Leach – Bliley de 1999 .......................................... .................................... 46
Uniendo y fortaleciendo a Estados Unidos proporcionando las herramientas adecuadas necesarias para
Ley de interceptación y obstrucción del terrorismo (Ley PATRIOTA de EE. UU.) De 2001 ......................... 46
Leyes estatales ................................................ .................................................. ....................... 47
Leyes internacionales de privacidad ............................................... ................................................. 52
Conclusión ................................................. .................................................. ..................... 55
Preguntas de revisión ................................................ .................................................. ........... 55
Ejercicios ................................................. .................................................. ....................... 56
Otras lecturas ................................................ .................................................. ............ 56
3 El proceso de auditoría de TI ............................................. .................................................. ... 59

Universo de auditoría ................................................ .................................................. ................ 59
COBIT ................................................. .................................................. ......................... 60
Evaluación de riesgos ................................................ .................................................. ............. 63
Plan de auditoría ................................................ .................................................. ...................... 64
Objetivos y contexto ............................................... ................................................ 68
Auditorías de TI realizadas para respaldar las auditorías de estados financieros ................................. 69
Página 9
Contenido ◾ ix
Programa de auditoría ................................................ .................................................. .......... 70

Presupuesto de auditoría y alcance .............................................. ............................................ 70
Equipo de auditoría, tareas y plazos ........................................... ................................... 70
Proceso de auditoría ................................................ .................................................. ................. 78
Revisión preliminar ................................................ .................................................. ... 78
Información general sobre el entorno de TI ............................................. ............. 79
Procedimientos de auditoría de diseño ............................................... .............................................. 80
Identificación de aplicaciones financieras ............................................... ........................... 80
Controles de prueba ................................................ .................................................. .............. 81
Pruebas sustantivas ................................................ .................................................. ... 83
Resultados del documento ................................................ .................................................. ...... 85
Resultados de la auditoría ................................................ .................................................. ....... 85
Conclusiones y Recomendaciones ............................................... ........................ 86
Comunicación ................................................. .................................................. ....... 86
Otros tipos de auditorías de TI ............................................. .................................................. ..91
Arquitectura empresarial ................................................ ................................................ 91
Sistemas y aplicaciones computarizados .............................................. ....................... 92
Instalaciones de procesamiento de información ............................................... .................................. 92
Desarrollo de sistemas ................................................ .................................................. 92
Planificación de la continuidad del negocio / Planificación de la recuperación ante desastres ........................... 92
Conclusión ................................................. .................................................. .................... 93
Preguntas de revisión ................................................ .................................................. .......... 93
Ejercicios ................................................. .................................................. ....................... 93
Otras lecturas ................................................ .................................................. ............ 95
4 Herramientas y técnicas utilizadas en la auditoría de TI .......................................... ...................... 97

Herramientas de productividad de auditoría ............................................... .................................................. .98
Planificación y seguimiento de auditorías .............................................. ........................................ 98
Documentación y presentaciones ............................................... ................................ 99
Comunicación ................................................. .................................................. ....... 99
Gestión de datos, documentos de trabajo electrónicos y software colaborativo ... 99
Administracion de recursos ................................................ ............................................... 101
Técnicas de documentación del sistema para comprender los sistemas de aplicación ......... 101
Diagramas de flujo como herramienta de análisis de auditoría ............................................ .............................. 103
Comprensión de cómo las aplicaciones procesan los datos ............................................. ............ 104
Identificación de documentos y su flujo a través del sistema ........................................... 104
Definición de elementos de datos ............................................... .............................................. 106
Desarrollo de diagramas de flujo ............................................... ................................. 106
Evaluación de la calidad de la documentación del sistema ............................................ ......... 106
Evaluación de controles sobre documentos .............................................. ............................. 106
Determinación de la eficacia del procesamiento de datos ............................................ .......... 107
Evaluación de la precisión, integridad y utilidad de los informes ........................... 107
Idoneidad de las técnicas de diagrama de flujo .............................................. .................... 107
Técnicas de auditoría asistidas por computadora (CAAT) .......................................... .................... 109
Partidas de interés de auditoría .............................................. .................................................. 110
Matemáticas de auditoría ................................................ .................................................. ... 110
Análisis de los datos ................................................ .................................................. ........... 110
Página 10
x ◾ Contenido
CAAT para muestreo ............................................... .................................................. ..... 113

Muestreo de atributos aleatorios y muestreo de variables ............................................ ...... 113
CAAT para revisiones de aplicaciones .............................................. ....................................... 115
Lenguaje de comandos de auditoría (ACL) ............................................ ................................. 115
Paso 1: Adquirir los datos ............................................ ........................................ 118
Paso 2: Acceder a los datos ............................................ ......................................... 118
Paso 3: Verificación de la integridad de los datos ......................................... .................... 118
Paso 4: Analizar y probar los datos .......................................... ....................... 119
Paso 5: Informar los hallazgos ............................................. ....................................... 119
CAAT para auditar controles de aplicaciones ............................................. ......................... 119
Controles de hoja de cálculo ................................................ .................................................. 119
Controles de base de datos ................................................ .................................................. ... 120
CAAT para revisiones operativas .............................................. ...................................... 120
Auditoría alrededor de la computadora versus auditoría a través de la computadora ...................... 121
Herramientas de informática forense ............................................... ................................................ 125
Conclusión ................................................. .................................................. ................... 125
Preguntas de revisión ................................................ .................................................. ........ 126
Ejercicios ................................................. .................................................. ..................... 126
Otras lecturas ................................................ .................................................. .......... 128
SECCIÓN II PLANIFICACIÓN Y ORGANIZACIÓN

5 Gobierno y estrategia de TI ............................................. ........................................ 133
Gobierno de TI: alineación de TI con objetivos comerciales ......................................... 134
Marcos de gobierno de TI ............................................... ............................................ 135
ITIL ................................................. .................................................. ........................ 135
COBIT ................................................. .................................................. ................... 135
ISO / IEC 27002 .............................................. .................................................. ......... 136
Un marco conjunto ............................................... .................................................. .... 137
Métricas de rendimiento de TI ............................................... .................................................. .137
Cuadro de mando integral de TI ............................................... ................................................ 139
Valor comercial generado por TI ............................................. .................................... 139
Orientación hacia el futuro................................................ ................................................. 140
Eficiencia y efectividad operativa .............................................. ................. 140
Satisfacción del servicio del usuario final ............................................. ................................... 140
Pasos para crear un cuadro de mando integral de TI ........................................... ................... 141
Cumplimiento normativo y controles internos ............................................. .................. 144
Estrategia de TI ................................................ .................................................. .................... 145
Comité Directivo de TI ............................................... .................................................. ..146
Comunicación ................................................. .................................................. .......... 147
Planificación operativa ................................................ .................................................. ... 148
Gestión de la demanda ................................................ ............................................... 149
Inicio del proyecto ................................................ .................................................. ...... 149
Revisión técnica ................................................ .................................................. ..... 149
Gestión de adquisiciones y proveedores .............................................. ........................ 150
Gestión financiera ................................................ ............................................... 150
Página 11
Contenido ◾ xi
Conclusión ................................................. .................................................. ................... 150

Preguntas de revisión ................................................ .................................................. ......... 151
Ejercicios ................................................. .................................................. ...................... 151
Otras lecturas ................................................ .................................................. ........... 152
6 Gestión de riesgos ............................................... .................................................. .... 155

Gestión de riesgos ................................................ .................................................. ......... 155
Gestión de riesgos empresariales — Marco integrado ............................................ ....... 157
Ambiente interno ................................................ ................................................. 158
Fijación de objetivos ................................................ .................................................. ...... 158
Identificación de eventos (o riesgos) ............................................ ......................................... 159
Evaluación de riesgos ................................................ .................................................. ....... 159
Respuesta a los riesgos ................................................ .................................................. .......... 160
Actividades de control ................................................ .................................................. ..... 161
Información y comunicación ............................................... ............................... 162
Supervisión ................................................. .................................................. .............. 163
Evaluación de riesgos ................................................ .................................................. ............ 163
Orientación disponible ................................................ .................................................. ....... 164
COBIT ................................................. .................................................. ................... 165
ISO / IEC ............................................... .................................................. .................... 165
Instituto Nacional de Estándares y Tecnología (NIST) ......................................... ..166
Oficina de Responsabilidad del Gobierno (GAO) ............................................ ..................... 167
Instituto Americano de Contadores Públicos Certificados (AICPA) .................................... 167
ISACA ................................................. .................................................. ..................... 168
Instituto de Auditores Internos (IIA) ........................................... .................................. 169
Comité de Organizaciones Patrocinadoras de la Comisión Treadway (COSO) ...... 169
El seguro como parte de las evaluaciones de riesgos de TI ........................................... ............................ 170
Riesgos de TI normalmente asegurados .............................................. ........................................... 170
Seguro cibernético ................................................ .................................................. ....... 171
Reducción y retención de riesgos ............................................. ................................. 171
Conclusión ................................................. .................................................. ................... 172
Ejercicios ................................................. .................................................. ...................... 174
Otras lecturas ................................................ .................................................. ........... 174
7 Gestión de proyectos ............................................... .................................................. 177

Gestión de proyectos ................................................ .................................................. ..... 177
Estándares de gestión de proyectos, autoridades líderes y metodologías ..................... 179
Factores clave para una gestión eficaz de proyectos ............................................ .................... 184
Planificación ................................................. .................................................. .................. 184
Administracion de recursos ................................................ ............................................... 188
Supervisión y seguimiento ............................................... ............................................... 188
Herramientas de gestión de proyectos ............................................... .......................................... 190
Certificación de gestión de proyectos ............................................... .............................. 191
Gestión de programas ................................................ .................................................. ..192
Gestión de proyectos: función del auditor ............................................. .................................. 193
Evaluación de riesgos ................................................ .................................................. ....... 193
Pagina 12
xii ◾ Contenido
Plan de auditoría ................................................ .................................................. ................ 194

Comunicación del alcance de la participación y recomendaciones ... 195
Gestión de proyectos de Big Data .............................................. .......................................... 195
Conclusión ................................................. .................................................. ................... 197
Ejercicios ................................................. .................................................. ...................... 198
Otras lecturas ................................................ .................................................. ........... 199
8 Ciclo de vida del desarrollo del sistema ............................................. .................................. 201

Ciclo de vida de desarrollo de sistemas .............................................. ........................................ 201
Planificación ................................................. .................................................. ................. 202
Análisis y requisitos del sistema .............................................. ............................. 203
Diseño de sistemas ................................................ .................................................. ......... 203
Desarrollo ................................................. .................................................. .......... 203
Pruebas ................................................. .................................................. ................... 205
Implementación ................................................. .................................................. ...... 208
Plan de IMPLEMENTACION ................................................ ............................................ 209
Procesos de conversión y limpieza de datos ............................................. ................. 209
Plan de desastre de TI ............................................... .................................................. .... 210
Documentación del sistema ................................................ .......................................... 211
Entrenamiento ................................................. .................................................. .............. 211
Soporte ................................................. .................................................. ............... 211
Operaciones y mantenimiento ............................................... ...................................... 212
Riesgos adicionales y controles asociados relacionados con las fases SDLC ................. 214
Enfoques para el desarrollo de sistemas .............................................. ................................. 215
Desarrollo del sistema de cascada ............................................... .................................... 215
Desarrollo de sistemas ágiles ............................................... .......................................... 215
Desarrollo de software adaptativo ............................................... ................................. 218
Desarrollo de aplicaciones conjuntas ............................................... ................................... 218
Creación de prototipos y desarrollo rápido de aplicaciones ............................................. ......... 219
Desarrollo de software ajustado ............................................... ...................................... 220
Desarrollo del usuario final .............................................. ................................................ 221
Participación del auditor de TI en el desarrollo y la implementación del sistema ... 223
Evaluación de riesgos ................................................ .................................................. ...... 224
Plan de auditoría ................................................ .................................................. ............... 224
Tarea de auditor: Análisis y requisitos del sistema ........................................... ..... 225
Tarea de auditor: Diseño del sistema ............................................. ................................... 226
Tarea de auditor: Desarrollo .............................................. .................................... 226
Tarea de auditor: Prueba .............................................. ............................................. 226
Tarea de auditor: Implementación .............................................. ................................ 227
Tarea de auditor: operaciones y mantenimiento ............................................ ............. 227
Comunicación ................................................. .................................................. ..... 232
Conclusión ................................................. .................................................. ................... 233
Ejercicios ................................................. .................................................. ..................... 234
Otras lecturas ................................................ .................................................. .......... 236
Página 13
Contenido ◾ xiii
SECCIÓN III AUDITORÍA DEL MEDIO AMBIENTE

9 Sistemas de aplicación: riesgos y controles ........................................... ...................... 241
Riesgos del sistema de aplicación ............................................... ................................................. 241
Seguridad de la información débil ............................................... ........................................ 243
Acceso no autorizado a programas o datos ............................................ .................... 243
Acceso remoto no autorizado ............................................... ..................................... 243
Información inexacta ................................................ ............................................. 243
Entrada de datos errónea o falsificada ............................................. ................................ 244
Procesamiento incompleto, duplicado e inoportuno ........................................... ........... 244
Fallo del sistema de comunicaciones ............................................... ................................ 244
Salida inexacta o incompleta .............................................. ................................ 244
Documentación insuficiente ................................................ ....................................... 245
Riesgos de la aplicación de desarrollo del usuario final ............................................ .......................... 245
Costos organizativos más altos ............................................... ..................................... 246
Sistemas incompatibles ................................................ ................................................ 246
Sistemas redundantes ................................................ .................................................. .246
Implementaciones ineficaces ................................................ ...................................... 246
Ausencia de segregación de funciones ............................................. ................................. 246
Análisis del sistema incompleto ............................................... ........................................ 247
Acceso no autorizado a datos o programas ............................................ ..................... 247
Violaciones de derechos de autor ................................................ .................................................. 247
Falta de opciones de respaldo y recuperación .......................................... ........................... 247
Destrucción de información por virus informáticos ............................................ ......... 248
Riesgos para los sistemas que intercambian información comercial electrónica .................. 249
Estándares para evaluaciones de auditoría EDI ............................................. ........................... 251
Riesgos de las aplicaciones web ............................................... .................................................. ... 252
Controles de aplicación ................................................ .................................................. ..... 253
Controles de entrada ................................................ .................................................. ......... 254
Autenticidad ................................................. .................................................. ....... 254
Exactitud ................................................. .................................................. ............ 254
Integridad ................................................. .................................................. ...... 255
Controles de procesamiento ................................................ .................................................. ..256
Exactitud e integridad ............................................... ................................... 256
Controles de salida ................................................ .................................................. ...... 258
Exactitud e integridad ............................................... ................................... 259
Distribución y retención ............................................... ..................................... 259
Participación del auditor de TI ............................................... ................................................. 259
Evaluación de riesgos ................................................ .................................................. ...... 260
Plan de auditoría ................................................ .................................................. ............... 260
Comunicación ................................................. .................................................. ...... 261
Conclusión ................................................. .................................................. ................... 261
Ejercicios ................................................. .................................................. ..................... 262
Otras lecturas ................................................ .................................................. .......... 263
Página 14
xiv ◾ Contenido
10 Gestión de control de cambios .............................................. .................................... 265

Importancia de un sistema de control de cambios ............................................ ........................... 266
Proceso de gestión de control de cambios .............................................. ............................. 266
Formulario de solicitud de cambio ............................................... ................................................. 267
Evaluación de impacto ................................................ .................................................. .. 269
Control S ................................................. .................................................. ................. 269
Cambios de emergencia ................................................ .................................................. .270
Cambiar documentación ................................................ ............................................. 270
Cambios de mantenimiento ................................................ ................................................ 270
Versiones de software ................................................ .................................................. ..... 271
Distribución de software ................................................ ................................................. 271
Procedimientos de gestión de control de cambios .............................................. ....................... 272
Objetivos ................................................. .................................................. .............. 272
Alcance ................................................. .................................................. ...................... 272
Juntas o Comités de Gestión de Control de Cambios ............................................ .. 272
Criterios para aprobar cambios .............................................. .................................. 273
Post-implementación ............................................... .................................................. .274
Puntos de origen e inicio del cambio ............................................ .................. 274
Puntos de aprobación ................................................ .................................................. ........ 275
Cambiar documentación ................................................ ............................................. 275
Puntos de revisión ................................................ .................................................. ........... 276
Gestión de la configuración ................................................ ........................................... 276
Gestión del cambio organizacional ............................................... ............................. 277
Definición de cultura organizacional ............................................... ................................ 278
Gestionar el cambio organizacional ............................................... ............................. 279
Participación en la auditoría ................................................ .................................................. ... 279
Conclusión ................................................. .................................................. .................. 282
Ejercicios ................................................. .................................................. ..................... 283
Otras lecturas ................................................ .................................................. .......... 289
11 Operaciones de sistemas de información .............................................. ................................ 291

Política y procedimientos operativos .............................................. ..................................... 292
Procesamiento de datos ................................................ .................................................. ........... 292
Protección de archivos y programas de datos ............................................ ............................... 294
Controles de acceso y seguridad física ............................................. .............................. 295
Controles ambientales ................................................ ................................................ 296
Copias de seguridad de programas y datos .............................................. ............................................. 297
Copias de seguridad en la nube ................................................ .................................................. ........ 299
Plan de negocios continuo ............................................... ................................................ 299
Plan de recuperación en un desastre ............................................... .................................................. .300
Componentes DRP ................................................ .................................................. .... 301
Auditoría de la informática del usuario final ............................................. ........................................ 302
Participación de la auditoría en las operaciones de los sistemas de información ............................................ ..... 302
Auditoría de centros de datos .............................................. ................................................. 304
Auditoría de un DRP .............................................. .................................................. ......... 304
Herramientas de auditoría ................................................ .................................................. .............. 305
Página 15
Contenido ◾ xv
Conclusión ................................................. .................................................. .................. 305

Ejercicios ................................................. .................................................. ...................... 310
Otras lecturas ................................................ .................................................. ........... 312
12 Seguridad de la información ............................................... ................................................. 315

Seguridad de información................................................ .................................................. ..... 317
Seguridad de la información en el entorno de TI actual ........................................... ......... 318
Planificación de recursos empresariales (ERP) ............................................ .............................. 318
Computación en la nube ................................................ .................................................. .... 319
Gestión de dispositivos móviles (MDM) ............................................ ............................ 319
Otros sistemas tecnológicos que impactan el entorno de TI ...................................... 320
Amenazas y riesgos de seguridad de la información ............................................. ............................. 321
Estándares de seguridad de la información ............................................... ....................................... 324
COBIT ................................................. .................................................. ................... 324
ISO / IEC 27002 .............................................. .................................................. .......... 325
NIST ................................................. .................................................. ....................... 327
Política de seguridad de la información ............................................... ............................................ 328
Designaciones de clasificación de información ............................................... .................... 330
Funciones y responsabilidades de seguridad de la información ............................................. ............... 330
Responsabilidades del propietario de la información ............................................... ............................ 331
Responsabilidades del custodio de la información ............................................... ...................... 331
Responsabilidades del usuario ................................................ .................................................. 331
Responsabilidades de terceros .............................................. ......................................... 331
Controles de seguridad de la información ............................................... ......................................... 332
Gestión de vulnerabilidades ................................................ ......................................... 332
Gestión de amenazas ................................................ .................................................. .333
Gestión de fideicomisos ................................................ .................................................. ... 333
Gestión de identidad ................................................ ................................................. 333
Administracion de incidentes ................................................ ............................................... 334
Selección y prueba de controles de seguridad de la información ........................................... ..... 334
Participación en una auditoría de seguridad de la información ............................................ .................. 336
Herramientas de auditoría y mejores prácticas ............................................. ...................................... 338
Conclusión ................................................. .................................................. ................... 338
Ejercicios ................................................. .................................................. ..................... 341
Otras lecturas ................................................ .................................................. .......... 342
13 Adquisición de sistemas, gestión de servicios y subcontratación ................................. 345

Estrategia
Proceso dede adquisición
adquisición dede sistemas
sistemas ...............................................
............................................... ...........................................346
............................................ 346
Definición de requisitos del sistema ............................................... .................................. 346
Identificación de alternativas ................................................ ............................................. 347
Realización de un análisis de viabilidad .............................................. ................................. 349
Realización de un análisis de riesgos .............................................. ......................................... 350
Realización del proceso de selección ............................................. ............................... 350
Adquisición del software seleccionado ............................................... ........................................ 353
Página 16
xvi ◾ Contenido
Completando la aceptación final ............................................... ..................................... 355

Gestión De Servicios ................................................ .................................................. ..... 355
Servicios de TI definidos ............................................... .................................................. ... 355
Acuerdos de Nivel de Servicio .............................................. ............................................. 356
Servicios de diseño y precios .............................................. ......................................... 356
Contratación y entrega de servicios .............................................. ............................... 358
Medidas de servicio ................................................ ................................................ 359
Qué medir ............................................... .................................................. ..359
Cómo medir ............................................... .................................................. .. 360
Herramientas de gestión de servicios ............................................... ..................................... 361
Subcontratación de sistemas informáticos ............................................... ................................................. 362
Participación en la auditoría de TI ............................................... .................................................. .... 365
Auditoría de adquisiciones de software ............................................... ................................... 365
Organizaciones de servicios de auditoría ............................................... ................................... 365
Conclusión ................................................. .................................................. ................... 367
Ejercicios ................................................. .................................................. ..................... 369
Otras lecturas ................................................ .................................................. ........... 370
Apéndice 1: Memorando de planificación de TI ............................................ ........................................... 373
Apéndice 2: Comprensión del entorno de TI ........................................... .................. 379
Apéndice 3: Ejemplos de programas de auditoría de TI para áreas de TI de control general ... 391
Apéndice 4: Procedimientos de mejores prácticas de ACL para probar los asientos del diario contable ... 411
Apéndice 5: Ejemplo de evaluación de riesgos de TI con NIST SP 800-30 ................................... 417
Apéndice 6: Ejemplo de política de gestión del control de cambios .......................................... ..... 435
Apéndice 7: Ejemplo de política de operaciones de sistemas de información .......................................... .441
Apéndice 8: Auditoría de grupos informáticos de usuarios finales ......................................... ............... 449
Apéndice 9: Áreas de control recomendadas para la auditoría de adquisiciones de software ... 453
Apéndice 10: Glosario .............................................. .................................................. ...... 459
Índice ................................................. .................................................. .............................. 471

Página 17
Prefacio
Motivación
A lo largo de los años, las organizaciones han experimentado numerosas pérdidas, que han tenido un impacto directo
impacto en su activo más valioso, la información. Los atacantes son capaces y continúan buscando
en busca de oportunidades para romper los sistemas informáticos tradicionales / no tradicionales y explotar su vulnerabilidad
habilidades. Ataques como el anterior, junto con la promulgación de leyes y reglamentos recientes, todos principalmente
relacionados con la protección de la información, han convertido la auditoría de tecnología de la información (TI) en una
profesión crítica, dinámica y desafiante con un futuro que trae el crecimiento hacia nuevos y emocionantes
ing áreas relacionadas con las TI.
Reconocí la importancia de escribir un libro que ayudaría a comprender las tecnologías de la información.
profesión de auditoría, haciendo hincapié en cómo la auditoría de TI proporciona a las organizaciones y auditores la capacid
evaluar eficazmente la validez, confiabilidad y seguridad de la información financiera. De particular importancia
era escribir sobre técnicas, procedimientos y controles que podrían ayudar a las organizaciones y
tadores para determinar si las actividades relacionadas con la recolección, procesamiento, almacenamiento y distribución
la información financiera es eficaz y coherente con las metas y objetivos de la organización. UN
Otro factor de motivación para escribir este libro fue cubrir material relevante típicamente probado en el
Exámenes de Auditor de sistemas de información certificado (CISA) y Contador público certificado (CPA)
(por ejemplo, controles internos, técnicas de auditoría asistidas por computadora (CAAT), conjuntos de habilidades tecnológ
etc.). Por último, quería escribir un libro que capturara el conocimiento y la experiencia que tengo.
ganado a lo largo de mi carrera de auditoría de TI.
Propósito
Este libro reconoce la necesidad continua de que las organizaciones y los auditores gestionen eficazmente
y examinar los sistemas de TI para cumplir con las metas y los objetivos comerciales. El libro proporciona esencia
principios fundamentales, conocimientos y habilidades sobre cómo controlar y evaluar los sistemas de TI que prepararán
lector para una carrera exitosa en la práctica pública, la industria privada o el gobierno. Dirigido a
tanto para estudiantes como para profesionales de la industria en los campos de TI y contabilidad, el libro:
◾ incluye problemas de auditoría de TI, simulaciones, casos prácticos y oportunidades de asignación de investigación
nidades para desarrollar la experiencia en auditoría de TI.
◾ está diseñado para satisfacer las crecientes necesidades de auditoría, cumplimiento, seguridad y gestión de riesgos de T
profesionales del ment.
◾ representa un recurso ideal para quienes se preparan para los exámenes CISA y CPA.
xvii
Página 18
xviii ◾ Prefacio
El libro está diseñado para su uso en un curso semestral de pregrado (nivel superior) y posgrado.
niveles. También está diseñado para encajar bien en un curso en línea. Contabilidad financiera y de gestión,
sistemas de información contable, sistemas de información de gestión y / o impresión de gestión
Los principios son todos requisitos previos sugeridos.
Nuevo en la quinta edición

Un cambio significativo de esta quinta edición es la reducción y / o consolidación de capítulos, desde
26 (edición anterior) a 13 capítulos, lo que permite a la facultad ajustar fácilmente los capítulos al curso
término (por ejemplo, curso de 16 semanas, curso de 8 semanas, etc.). Cada capítulo ha sido revisado significativamente par
incluir conceptos, ejemplos, herramientas y / o técnicas de auditoría actualizados, incluido el final del capítulo
casos con escenarios prácticos de auditoría de TI. Estos escenarios requieren que los estudiantes trabajen individualmente
aliados o en equipos, participar en discusiones en el aula, realizar análisis y tomar decisiones
haciendo estrategias. La quinta edición está diseñada para temas de auditoría, técnicas informáticas y otros
conjuntos de habilidades tecnológicas y conceptos que normalmente se evalúan en los exámenes CISA y CPA.
Otra contribución significativa es la adición o revisión de recursos y materiales didácticos.
que permiten a los profesores centrar su atención en la presentación y el debate en el aula. Disponible
los recursos y el material incluyen:
◾ Diapositivas de presentación de PowerPoint significativamente mejoradas, con información adicional relevante

en la sección de notas.
◾ Bancos de prueba certificados por el autor, que garantizan la prueba de habilidades cognitivas de alto nivel y no solo
sobre la memorización de textos. Los bancos de pruebas incluyen preguntas de opción múltiple, verdadero o falso, y d
que evalúan el contenido, además de requerir habilidades de análisis, síntesis y evaluación.
◾ Manual del instructor revisado.
◾ Plantilla de plan de estudios con horarios de clases sugeridos para cursos de 16 y 8 semanas.
Organización y contenido del capítulo

El libro se divide en tres secciones principales:
Sección I — Fundamentos de la auditoría de TI (cuatro capítulos)
El capítulo 1 analiza cómo la tecnología evoluciona constantemente y da forma al entorno empresarial actual.
mentos. El capítulo también habla de la profesión de auditoría, con especial interés en la auditoría de TI.
Tras la discusión de auditoría, se describen las tendencias y necesidades actuales de auditoría de TI,
así como las diversas funciones de un auditor en el campo de las TI. El capítulo termina con explicaciones de
por qué la auditoría de TI se considera una profesión y las diversas oportunidades profesionales disponibles para TI
auditores.
El capítulo 2 se centra en la legislación federal, estatal e internacional que rige el uso, mal uso,
y privacidad de la información y su tecnología relacionada. La legislación tiene un impacto duradero en la
comunidad en línea (gobierno, empresas y el público), que es algo que aquellos que ingresan
la profesión de auditoría de TI debe tener conocimiento.
El capítulo 3 analiza el proceso de auditoría para TI y las demandas que se impondrán al pro-
fesión en el futuro. El capítulo cubre evaluaciones de riesgos, planificación de auditorías, fases requeridas de un
Página 19
Prefacio ◾ xix
El compromiso de auditoría de TI y la importancia de la documentación de auditoría de TI al respaldar

auditorías de estados.
El Capítulo 4 define las herramientas de productividad de auditoría y describe cómo ayudan al proceso de auditoría. los
El capítulo luego aborda las diversas técnicas utilizadas para documentar los sistemas de aplicación financiera.
Las explicaciones de las CAAT y el papel que desempeñan en la auditoría seguirán junto con descripciones de
las diversas técnicas utilizadas al definir el tamaño de la muestra de auditoría, seleccionar muestras y revisar
aplicaciones. Los CAAT utilizados en la auditoría de los controles de aplicación y en las revisiones operativas se
descrito seguido de explicaciones de herramientas y técnicas informáticas forenses.
Sección II — Planificación y organización (cuatro capítulos)
El capítulo 5 reconoce la globalización existente de muchas industrias y mercados financieros,

y destaca la importancia de una gobernanza y controles eficaces para el éxito de las organizaciones.
La Ley Sarbanes-Oxley de 2002, el Comité de Organizaciones Patrocinadoras de Treadway
Comisión, el Código Combinado de Gobernanza en el Reino Unido y la Organización
para la cooperación económica y los principios de desarrollo de la gobernanza empresarial en Europa
todos han puesto el listón para el gobierno corporativo global. Para TI, objetivos de control para la información
and Related Technology (COBIT) se ha convertido en el estándar mundial para la gobernanza. Gobierno de TI
proporciona la estructura y la dirección para lograr la alineación de la estrategia de TI con el negocio
estrategia.
El Capítulo 6 analiza el proceso de gestión y evaluación de riesgos en un entorno de TI. Riesgo
La gestión debe integrarse en la planificación estratégica, la planificación operativa, la gestión de proyectos.
gestión, asignación de recursos y operaciones diarias, ya que permite a las organizaciones centrarse en áreas
que tienen el mayor impacto. Las evaluaciones de riesgo, por otro lado, ocurren en múltiples niveles del
organización con enfoque en diferentes áreas. ¿Cuáles son las características y componentes de un riesgo?
¿proceso de gestión? ¿Cuáles son los estándares profesionales de práctica para las evaluaciones de riesgos? Qué
¿Se utilizan ejemplos de prácticas de evaluación de riesgos en diversos entornos? Estas son algunas de las preguntas
ciones que serán respondidas dentro del capítulo.
El capítulo 7 se centra en las mejores prácticas, estándares y metodologías de gestión de proyectos utilizados.
por los gerentes para poner fin a los proyectos de manera efectiva y eficiente. El capítulo también analiza
factores al realizar una gestión de proyectos eficaz, así como el papel del auditor en el proyecto
administración. Temas como la gestión de proyectos de TI y la gestión de proyectos de big data son
también discutido.
El capítulo 8 analiza el ciclo de vida del desarrollo del sistema y sus fases comunes, así como los riesgos.
y controles asociados relacionados con dichas fases. El capítulo también explica los enfoques comunes utilizados
para el desarrollo de software, y termina con una discusión sobre la participación del auditor de TI en el sistema
proceso de desarrollo e implementación.
Sección III — Auditoría del entorno de TI (cinco capítulos)

El capítulo 9 analiza los riesgos comunes a varios tipos de sistemas de aplicación y proporciona un examen
ples de tales riesgos potenciales. El capítulo también toca los controles de aplicación relevantes (es decir,
entrada, procesamiento y salida) que pueden implementar las organizaciones para mitigar
los riesgos discutidos. Por último, la participación de los auditores de TI al examinar las aplicaciones es
explicado.
El capítulo 10 analiza los procesos y procedimientos de gestión para el control y la organización de cambios.
cambio organizacional. Este capítulo también describe la gestión de la configuración y las actividades de muestra.
Página 20
xx ◾ Prefacio
realizado como parte de un plan de gestión de la configuración. Este capítulo termina con una discusión sobre TI
participación de la auditoría en un examen de gestión de control de cambios.
El capítulo 11 presenta una descripción general de las operaciones de los sistemas de información como componente rel
de la infraestructura de TI. Este capítulo proporciona ejemplos de objetivos y actividades de control que TI
El auditor debe enfocarse al examinar las operaciones de los sistemas de información. Este capítulo también cubre
grupos informáticos de usuarios finales y proporciona directrices para la auditoría de dichos grupos. Por último, auditoría de
La participación se discute al examinar las operaciones de los sistemas de información, incluido el procedimiento.
duros a seguir al auditar centros de datos y planes de recuperación ante desastres, entre otros.
El Capítulo 12 describe la importancia de la seguridad de la información para las organizaciones y cómo
mación representa un activo fundamental en el entorno empresarial actual. Este capítulo también analiza
tecnologías recientes que están revolucionando las organizaciones y, en concreto, la necesidad de implementar
seguridad adecuada para proteger la información. Amenazas y riesgos de seguridad de la información, y cómo
continúan afectando los sistemas de información también se describen. Estándares de seguridad de la información relevantes
y las directrices disponibles para las organizaciones y los auditores se discutirán, junto con las firmas
Importancia de establecer una política de seguridad de la información. Este capítulo continúa con una discusión
de roles y responsabilidades del personal de seguridad de la información. Para finalizar, explicaciones de información
controles de seguridad, la importancia de seleccionar, implementar y probar dichos controles, y la
Se proporciona la participación de auditoría de TI en una evaluación de seguridad de la información.
El capítulo 13 analiza los factores críticos de éxito al adquirir sistemas o servicios de terceros.
fiestas. Este capítulo también cubre la gestión del servicio y las expectativas de una asociación eficaz.
entre organizaciones y proveedores. La subcontratación de TI, que se analiza a continuación, se refiere a la contratación de u
empresa para manejar la totalidad o parte de las actividades de procesamiento de TI de una organización, lo que permite a la
para centrarse en lo que hacen mejor. Por último, la participación de la auditoría de TI al examinar las adquisiciones de siste
y se describen los servicios de TI subcontratados.
Objetivos clave de aprendizaje

◾ Discutir cómo la tecnología evoluciona constantemente y da forma a los entornos de TI actuales. A
Explique la profesión de auditoría de TI, los roles del auditor de TI y las oportunidades profesionales.
◾ Describir la legislación relevante para los auditores de TI y su impacto en el campo de las TI. Para ilustrar
delitos y ciberataques en Internet denunciados con frecuencia. Desarrollar planes y procedimientos de auditoría.
que ayudan a las organizaciones a cumplir con las leyes y reglamentos pertinentes.
◾ Para explicar el proceso de auditoría de TI, la importancia de los objetivos de control para la información
y Tecnología Relacionada (COBIT), y las diversas fases de un trabajo de auditoría de TI. A
Desarrollar documentación relevante y práctica para realizar el trabajo de auditoría de TI.
◾ Apoyar el papel y la importancia de las herramientas y las técnicas de auditoría asistida por computadora (CAAT)
al realizar el trabajo de auditoría. Diseñar planes de auditoría que aseguren el uso adecuado de herramientas y
tecnologías al realizar el trabajo de auditoría.
◾ Demostrar la importancia de alinear los planes, objetivos y estrategias de TI con las
negocio (es decir, gobierno de TI).
◾ Explicar la gestión de riesgos, particularmente la Gestión de Riesgos Empresariales — Integrada
Marco de referencia. Describir las evaluaciones de riesgos y cómo forman el primer paso en la gestión de riesgos.
metodología de gestión.
◾ Describir la gestión de proyectos, así como los estándares de gestión de proyectos y las mejores prácticas.
tices. Discutir el papel del auditor de TI en la gestión de proyectos.
Página 21
Prefacio ◾ xxi
◾ Resumir el ciclo de vida del desarrollo del sistema (SDLC), enfoques comunes, riesgos, asociaciones
controles y la participación del auditor de TI. Desarrollar programas de auditoría relevantes que enumeren los riesgos
relacionados con las fases de SDLC y los controles y procedimientos de TI necesarios para mitigar esos riesgos.
◾ Discutir los riesgos asociados con tipos comunes de sistemas de aplicación, así como la aplicación
controles y cómo se utilizan para salvaguardar la entrada, el procesamiento y la salida de información
ción. Discutir la participación del auditor de TI en un examen de sistemas de aplicación. A
Desarrollar documentación relevante y práctica para realizar el trabajo de auditoría de TI.
◾ Establecer la importancia de un proceso de gestión de control de cambios. Para ilustrar la auditoría
participación en un examen de gestión de control de cambios. Para realizar el trabajo de auditoría real
relacionados con la gestión del control de cambios, desde la comprensión del entorno de TI
ambiente a través de la comunicación formal de los resultados de la auditoría a la gerencia.
◾ Demostrar la importancia para las organizaciones de haber implementado políticas,
procedimientos y controles adecuados relacionados con las operaciones de los sistemas de información para garantiza
integridad, exactitud y validez de la información. Describir la participación de la auditoría en un
examen de las operaciones de los sistemas de información de una organización. Para diseñar y preparar
documentación relevante y práctica al realizar el trabajo de auditoría de TI.
◾ Respaldar la importancia de proteger la información contra amenazas y riesgos de seguridad, y
Implementar políticas, procedimientos y controles de seguridad de la información efectivos para garantizar
la integridad de dicha información. Para describir la participación de la auditoría en una seguridad de la información.
examen.
◾ Explicar la importancia de una estrategia de abastecimiento como factor crítico de éxito para adquirir TI.
servicios o productos. Discutir cómo se deben definir los servicios de TI para cumplir
objetivos y cómo medir el desempeño de esos servicios de TI.
Página 23
22
Expresiones de gratitud
Empiezo agradeciendo a Dios por todas las bendiciones, la vida misma, la familia, los amigos y ahora la oportunidad.
para completar este libro. A continuación, extiendo mi más profundo agradecimiento al Sr. Richard O'Hanley de CRC
Press y Auerbach Publications, que creyeron en mí y confiaron en que podemos realizar un gran trabajo
juntos. Estoy especialmente agradecido con el equipo de desarrollo editorial y los revisores de la facultad, que
mejoró la calidad de este libro con sus invaluables sugerencias, comentarios y constructivos
crítica. La profundidad y sinceridad de sus reseñas evidenciaron claramente su devoción y pasión por
el campo de la auditoría de TI. Tuve el privilegio de contar con sus sinceros y valiosos consejos, que sin duda
agregó un valor significativo a esta quinta edición.
A los colegas y amigos, gracias por su tiempo, orientación, consejos, conocimientos y apoyo.
siempre, todo fundamental para animarme a comprometerme con el desafiante viaje de escribir un libro.
A mis padres, Angel L. Otero y Lydia E. Rivera, mis hermanos, Dr. Luis Daniel Otero y
Dr. Carlos Otero, gracias a todos por servir como grandes modelos a seguir, personal y profesionalmente.
Gracias por su constante apoyo, aliento y por desafiarme siempre a trabajar en
el siguiente nivel.
A mis hijos Elizabeth, Leonardo y Giancarlo, espero que el logro que logré
hoy te sirve de aliento y motivación. Recuerda trabajar siempre duro sin
dañar a tu prójimo, nunca te conformes con menos y condiciona tu mentalidad para la grandeza. Sea respetuoso
llenos, sean humildes y, lo más importante, pongan siempre a Dios en primer lugar en sus vidas.
Por último, pero ciertamente no menos importante, mi más sincero agradecimiento a mi encantadora esposa y mejor am
Gracias por creer en mí desde el día en que me embarqué en este esfuerzo. Gracias por su
gran ayuda, estímulo continuo y apoyo en la crianza de nuestros hijos. Gracias por su
amor incondicional y las noches de insomnio durante los últimos años. Debo la terminación
de este libro para ti y todos los sacrificios que hiciste. Te amo con todas las fuerzas de mi corazón.
xxiii
Página 25
24
Autor
Angel R. Otero, Ph.D., CPA, CISA, CITP, CICA, CRISC es profesor asistente de contabilidad
ing y presidente del programa para programas en línea de contabilidad y finanzas en la Facultad de Negocios
en el Instituto de Tecnología de Florida (Florida Tech o FIT), Melbourne, FL. El Dr. Otero tiene una licenciatura
en contabilidad de la Universidad Estatal de Pensilvania, una maestría en ingeniería de software de Florida
Tech y un Ph.D. en sistemas de información de Nova Southeastern University. El tambien tiene
membresías activas en el Instituto Americano de Contadores Públicos Certificados (AICPA), ISACA
(anteriormente Asociación de Auditoría y Control de Sistemas de Información) y el Instituto de
Controla las organizaciones profesionales (IIC).
El Dr. Otero tiene más de 20 años de experiencia en la industria en las áreas de contabilidad / auditoría pública,
auditoría de sistemas de información, auditorías de control interno y consultoría en tecnología de la información.
Los clientes atendidos incluyen las industrias de banca / finanzas, seguros, gobierno, manufactura,
minorista y mayorista, entre otros. Antes de unirse a FIT, el Dr. Otero trabajó en Deloitte & Touche,
LLP durante más de 10 años y obtuvo el puesto de gerente senior que supervisa las oficinas en el estado
de Florida y Puerto Rico.
Los intereses de investigación del Dr. Otero incluyen (1) auditoría de sistemas / tecnología de información; (2) cuenta
ing sistemas de información; (3) auditorías financieras y controles internos; y (4) seguridad de la información
auditorías y evaluaciones de riesgos. Ha publicado en múltiples revistas y conferencias revisadas por pares.
actas.
xxv
Página 27
26
FUNDACIÓN yo
PARA LA AUDITORÍA
Página 29
28
Capítulo 1
Auditoría de medio ambiente y TI
OBJETIVOS DE APRENDIZAJE
1. Analice cómo la tecnología evoluciona constantemente y da forma a los entornos empresariales (TI) actuales.
2. Analice la profesión de auditor y defina la auditoría financiera.
3. Diferenciar entre los dos tipos de funciones de auditoría que existen en la actualidad (internas y
externo).
4. Explique qué es la auditoría de TI y resuma sus dos grandes grupos.
5. Describa las tendencias actuales de auditoría de TI e identifique las necesidades de tener una auditoría de TI.
6. Explique las diversas funciones del auditor de TI.
7. Respalde por qué la auditoría de TI se considera una profesión.
8. Describa el perfil de un auditor de TI en términos de experiencia y habilidades requeridas.
9. Analice las oportunidades profesionales disponibles para los auditores de TI.
Las organizaciones de hoy dependen más de la información y son más conscientes de la naturaleza omnipresente de
tecnología en toda la empresa comercial. La mayor conectividad y disponibilidad de los sistemas.
y los entornos abiertos han demostrado ser el sustento de la mayoría de las entidades comerciales. Información de tecnología
La tecnología (TI) se utiliza ahora más ampliamente en todas las áreas del comercio en todo el mundo.
Entorno de TI
La necesidad de un mejor control de la TI, especialmente en el comercio, ha avanzado a lo largo de los años.
en estudios anteriores y continuos de muchas organizaciones nacionales e internacionales. Esencialmente,
La tecnología ha impactado varias áreas importantes del entorno empresarial, incluido el uso
y procesamiento de información, el proceso de control y la profesión de auditor.
Página 30
4 ◾ Control y auditoría de tecnologías de la información
◾ La tecnología ha mejorado la capacidad de capturar, almacenar, analizar y procesar enormes

cantidades de datos e información, ampliando el empoderamiento de la decisión empresarial
fabricante. También se ha convertido en un facilitador principal de los procesos de producción y servicio. Ahi esta
un efecto residual en el sentido de que el mayor uso de la tecnología ha dado lugar a un aumento de los presupuestos,
mayores éxitos y fracasos, y una mejor conciencia de la necesidad de control .
◾ La tecnología ha tenido un impacto significativo en el proceso de control de los sistemas. Aunque con-
Los objetivos de control generalmente se han mantenido constantes, excepto para algunos que son
específico, la tecnología ha alterado la forma en que se deben controlar los sistemas. Salvaguardar
activos , como objetivo de control, sigue siendo el mismo si se hace manualmente o de forma automática.
Sin embargo, la forma en que se cumple el objetivo de control ciertamente se ve afectada.
◾ La tecnología ha impactado a la profesión de auditoría en términos de cómo se realizan las auditorías.
(captura y análisis de información, preocupaciones de control) y el conocimiento requerido para
sacar conclusiones con respecto a la eficacia, la eficiencia y los informes operativos o del sistema
integridad . Inicialmente, el impacto se centró en lidiar con un entorno de procesamiento modificado
ambiente. A medida que crecía la necesidad de auditores con habilidades tecnológicas especializadas, también lo hiz
profesión de auditoría.
La tecnología está en constante evolución y encuentra formas de dar forma al entorno de TI actual en la organización.
nización. Las siguientes secciones describen brevemente varias tecnologías recientes que han
ciertamente continúan revolucionando las organizaciones, la forma en que se hacen negocios y la dinámica de la
lugar de trabajo.
Planificación de recursos empresariales (ERP)

Según la edición de junio de 2016 de Apps Run the World, una empresa de investigación de mercado de tecnología
pany dedicada al espacio de aplicaciones, el mercado mundial de sistemas ERP alcanzará los 84,1 dólares
mil millones en 2020 frente a $ 82.1 mil millones en 2015. ERP es un software que proporciona
funcionalidad en un sistema de entorno de TI integrado (por ejemplo, adquisiciones, inventario, contabilidad ,
y recursos humanos [RRHH]). Consulte el Anexo 1.1 para ver una ilustración del sistema modular ERP.
Los ERP permiten que múltiples funciones accedan a una base de datos común, lo que reduce los costos de almacenami
aumentando la coherencia y precisión de los datos de una única fuente. Además, los ERP:
◾ Disponer de métodos estándar para automatizar procesos (es decir, información en el sistema de RR.
tem puede ser utilizado por nómina, mesa de ayuda, etc.).
◾ Comparta información en tiempo real de los módulos (finanzas, recursos humanos, etc.) que residen en un
base de datos, por lo tanto, los estados financieros , análisis e informes se generan más rápido y más
frecuentemente.
Algunos de los principales proveedores de ERP en la actualidad incluyen SAP, FIS Global, Oracle, Fiserv, Intuit, Inc.,
Cerner Corporation, Microsoft, Ericsson, Infor y McKesson.
A pesar de las muchas ventajas de los ERP, no son muy diferentes de los comprados o empaquetados.
sistemas antiguos y, por lo tanto, pueden requerir modificaciones importantes a los programas comerciales nuevos o existent
cesses. Las modificaciones de ERP (es decir, las versiones de software) requieren una programación considerable para actua
del código específico de la organización. Dado que los sistemas empaquetados son genéricos por naturaleza, las organizacio
pueden necesitar modificar sus operaciones comerciales para que coincidan con el método de procesamiento del proveedor,
ejemplo. Los cambios en las operaciones comerciales pueden no encajar bien en la cultura de la organización u otras
procesos, y también puede ser costoso debido a la capacitación. Además, dado que los ERP son ofrecidos por un
Página 31
Entorno de tecnología de la información y auditoría de TI ◾ 5
Financiero
recurso
administración
Humano
Cadena de suministro
recurso
administración
Empresa administración
recurso
planificación
(DB común)
Fabricación Cliente
recurso relación
planificación administración
Figura 1.1 Sistema modular de planificación de recursos empresariales.
proveedor, los riesgos asociados con tener un solo proveedor se aplican (por ejemplo, dependiendo de un solo proveedor par
mantenimiento y soporte, requisitos específicos de hardware o software, etc.).
Computación en la nube
La computación en la nube sigue teniendo un impacto cada vez mayor en el entorno de TI. De acuerdo a
ISACA (anteriormente conocida como Asociación de Control y Auditoría de Sistemas de Información), la nube
El crecimiento exponencial de la informática ya no debería considerarse una tecnología emergente. Nube
La informática ha dado forma a los negocios en todo el mundo, y algunas organizaciones la utilizan para realizar
Procesos críticos para el negocio. Basado en el informe ISACA Innovation Insights de julio de 2015, la nube
la informática se considera una de las tendencias clave que impulsa la estrategia empresarial . Los datos internacionales
Corporation, en su publicación de 2015, también predice que la computación en la nube crecerá un 19,4% anual.
aliado durante los próximos 5 años. Además, el informe de computación en la nube de la perspectiva 2016 de Deloitte (infor
indica que para las empresas privadas, la computación en la nube seguirá siendo un factor dominante.
La computación en la nube, según la definición de PC Magazine, se refiere al uso de Internet (frente a la
disco duro de la computadora) para almacenar y acceder a datos y programas. De manera más formal, el National
El Instituto de Estándares y Tecnología (NIST) define la computación en la nube como un "modelo para permitir
Acceso a la red ubicuo, conveniente y bajo demanda a un grupo compartido de computación configurable
recursos (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que se pueden proporcionar rápidamente
mencionado y publicado con un mínimo esfuerzo de gestión o interacción del proveedor de servicios ". NIST también
enfatice que la disponibilidad es promovida significativamente por este modelo particular (nube).
Los servicios altamente flexibles que se pueden administrar en el entorno virtual hacen que la nube
informática muy atractiva para las organizaciones empresariales. No obstante, las organizaciones aún no se sienten
Página 32
totalmente cómodo al almacenar su información y aplicaciones en sistemas que residen fuera de

sus instalaciones en el lugar. Migrar información a una infraestructura compartida (como un entorno de nube
ambiente) expone la información sensible / crítica de las organizaciones a riesgos de posibles riesgos no autorizados
acceso y exposición, entre otros. Deloitte, una de las empresas de contabilidad y auditoría más importantes del mundo
empresas, también respalda la importancia de la seguridad y la privacidad anterior, y agregó, en base a su informe,
que la información almacenada en la nube relacionada con los datos del paciente, los datos bancarios y los registros del pers
nombrar algunos, es vulnerable y susceptible de mal uso si cae en las manos equivocadas.
Gestión de dispositivos móviles (MDM)

MDM, también conocido como Enterprise Mobility Management, es un término relativamente nuevo, pero ya
dar forma al entorno de TI en las organizaciones. MDM es responsable de gestionar y administrar
dispositivos móviles (por ejemplo, teléfonos inteligentes, computadoras portátiles, tabletas, impresoras móviles, etc.) propor
como parte de sus responsabilidades laborales. Específicamente, y según PC Magazine, MDM asegura
estos dispositivos móviles:
◾ integrarse bien dentro de la organización y se implementan para cumplir con la organización

Policias y procedimientos
◾ proteger la información corporativa (por ejemplo, correos electrónicos, documentos corporativos, etc.) y la configuraci
configuración para todos los dispositivos móviles dentro de la organización
Los empleados también utilizan los dispositivos móviles por motivos personales. Es decir, los empleados traen sus propios
dispositivo móvil (personal) a la organización (también denominado traiga su propio dispositivo o BYOD)
para realizar su trabajo. Permitir que los empleados utilicen dispositivos móviles proporcionados por la organización para tra
y las razones personales han demostrado ser atractivas para el empleado medio. Sin embargo, las organizaciones
debe monitorear y controlar las tareas realizadas por los empleados cuando usan dispositivos móviles, y
asegurar que los empleados se mantengan enfocados y productivos. Representa un riesgo para la organización
seguridad y una distracción para los empleados cuando los dispositivos móviles se utilizan para fines personales y laborales
poses. Además, permitir el acceso directo a la información corporativa siempre representa un
riesgo, así como también plantea preocupaciones de seguridad y cumplimiento para la organización.
Otros sistemas tecnológicos que afectan el entorno de TI

Internet de las cosas (IoT) tiene un efecto transformador potencial en los entornos de TI,
centros, proveedores de tecnología, etc. Gartner, Inc. estima que para el año 2020, IoT incluirá
26 mil millones de unidades instaladas y los ingresos superarán los $ 300 mil millones generados principalmente por produc
y proveedores
IoT, segúnde
lo servicios.
define Gartner, Inc., es un sistema que permite que los activos remotos de "cosas" (por ejemplo, dispositiv
sensores, objetos, etc.) para interactuar y comunicarse entre ellos y con otros sistemas de red.
Los activos, por ejemplo, comunican información sobre su estado real, ubicación y funcionalidad,
entre otros. Esta información no solo proporciona una comprensión más precisa de los activos, sino que
también maximiza su utilización y productividad, lo que resulta en un proceso mejorado de toma de decisiones.
Los enormes volúmenes de datos sin procesar o conjuntos de datos (también conocidos como Big Data) generados como res
las interacciones masivas entre dispositivos y sistemas deben procesarse y analizarse de manera efectiva en
para generar información significativa y útil en el proceso de toma de decisiones.
Big Data, según la definición de la Comisión Federal de Big Data de la TechAmerica Foundation (2012),
“Describe grandes volúmenes de datos variables, complejos y de alta velocidad que requieren
Página 33
técnicas y tecnologías para permitir la captura, almacenamiento, distribución, gestión y análisis

sis de la información ". Gartner, Inc. lo define además como "... alto volumen, alta velocidad y /
o activos de información de gran variedad que exigen formas de información innovadoras y rentables
procesamiento que permite una mejor comprensión, toma de decisiones y automatización de procesos ".
A pesar de que Big Data preciso puede conducir a un proceso de toma de decisiones más seguro, y
ter decisiones a menudo resultan en una mayor eficiencia operativa, reducción de costos y reducción del riesgo, muchos
Actualmente existen desafíos que deben abordarse.
Los desafíos de Big Data incluyen, por ejemplo, análisis, captura, curación de datos, búsqueda, intercambio,
almacenamiento, transferencia, visualización, consulta, así como actualización. Ernst & Young, en su EY Center
para la publicación Board Matters de septiembre de 2015, establece que los desafíos para los auditores incluyen
acceso limitado a datos relevantes de auditoría , la escasez de personal disponible y calificado para procesar
y analizar esos datos particulares y la integración oportuna de los análisis en la auditoría. El IoT
también entrega datos en rápido movimiento de sensores y dispositivos en todo el mundo y, por lo tanto, da como resultado
desafíos similares para muchas organizaciones a la hora de dar sentido a todos esos datos.
Otras tecnologías recientes enumeradas en el ciclo Hype 2015 de Gartner para tecnologías emergentes
Los informes que actualmente están afectando los entornos de TI incluyen dispositivos portátiles (por ejemplo, relojes intelig
vehículos autónomos, criptomonedas, impresión 3D de consumo y traducción de voz a voz,
entre otros.
Entorno de TI como parte de la estrategia de la organización

En el entorno actual, las organizaciones deben integrar su TI con estrategias comerciales para lograr
sus objetivos generales, sacar el máximo provecho de su información y capitalizar la tecnología
gies disponibles para ellos. Donde antes se veía a TI como un habilitador de la estrategia de una organización,
ahora se considera una parte integral de esa estrategia para lograr rentabilidad y servicio. En el
Al mismo tiempo, cuestiones como el gobierno de TI, la infraestructura de información internacional, la seguridad y
la privacidad y el control de la información pública y de la organización han impulsado la necesidad de una autoevaluación
y seguridad en uno mismo.
Para el gerente de TI, las palabras "auditoría" y "auditor" provocan escalofríos por la columna vertebral. Si,
el auditor o la auditoría se ha considerado un mal que debe ser tratado por todos los gerentes. En
En el campo de las tecnologías de la información, los auditores en el pasado debían recibir capacitación o orientación en con
operaciones para evaluar las prácticas y aplicaciones de TI. Los gerentes de TI se estremecen ante la capacidad del auditor p
evaluar de forma eficaz y eficiente las complejidades y comprender los problemas. Hoy en día, los auditores de TI son
Se espera que conozca bien la infraestructura, las políticas y las operaciones de TI de la organización antes
embarcarse en sus revisiones y exámenes. Más importante aún, los auditores de TI deben ser capaces
de determinar si los controles de TI implementados por la organización garantizan la protección de datos y
alinearse adecuadamente con los objetivos generales de la organización.
Asociaciones y organizaciones profesionales como ISACA, el Instituto Americano de
Contadores Públicos Certificados (AICPA) , Instituto Canadiense de Contadores Públicos
(CICA), Instituto de Auditores Internos (IIA), Asociación de Examinadores de Fraude Certificados (ACFE),
y otros han emitido guías, instrucciones y apoyado estudios e investigaciones en áreas de auditoría.
La profesión de auditor
Las computadoras se han utilizado comercialmente desde 1952. Los delitos relacionados con las computadoras se informaro
ya en 1966. Sin embargo, no fue hasta 1973, cuando los importantes problemas de Equity Funding
Página 34
Corporation of America (EFCA) surgió, que la profesión de auditoría miró seriamente la falta de
de controles en sistemas informáticos de información (SI). En 2002, casi 30 años después, otro importante
el fraude resultó de escándalos corporativos y contables (Enron y WorldCom), que trajeron consigo
escepticismo y caída de los mercados financieros. Esta vez, ni las principales firmas contables
ni las empresas reguladas por valores y cambios en las principales bolsas pudieron evitar la
indignación pública, falta de confianza de los inversores y una mayor regulación gubernamental que
Economía estadounidense. Una vez más, en 2008, la economía de EE. UU. Sufrió debido a la banca hipotecaria y
empresas de inversión (como Countrywide, IndyMac, etc.) incumplieron los pagos de préstamos poco sólidos
estrategias y mala gestión de riesgos.
Cuando EFCA se declaró en quiebra en 1973, el impacto directo mínimo y las pérdidas de
se informó que la actividad ascendía a 200 millones de dólares. Otras estimaciones de este importante
el fraude aumentó a $ 2 mil millones, con costos indirectos como honorarios legales y depreciación
incluido. Estas pérdidas fueron el resultado de un "fraude asistido por computadora" en el que una corporación falsificó
Fied los registros de su subsidiaria de seguros de vida para indicar la emisión de nuevas pólizas. Además de-
a las pólizas de seguro, otros activos, como cuentas por cobrar y valores negociables , fueron
registrado falsamente. Estos activos ficticios deberían haberse revelado como inexistentes durante la corporación
las auditorías regulares de fin de año de la ración, pero nunca se descubrieron. Como se utilizó la computadora para manipul
archivos tardíos como un medio para cubrir el fraude, la profesión contable se dio cuenta de que los
Las técnicas manuales pueden no ser adecuadas para trabajos de auditoría que involucran aplicaciones informáticas.
En 1973, la AICPA (principal organización profesional nacional de contadores públicos certificados),
en respuesta a los eventos en EFCA, nombró un comité especial para estudiar si la auditoría
los estándares del día eran adecuados en tales situaciones. Se solicitó al comité que evaluara
los procedimientos específicos que se utilizarán y las normas generales que se aprobarán. En 1975, el compromiso
tee emitió sus conclusiones . Aunque el comité especial encontró que las normas de auditoría eran
adecuado, y que no se requirieron cambios importantes en los procedimientos utilizados por los auditores,
Se emitieron varias observaciones y recomendaciones relacionadas con el uso de programas informáticos.
diseñado para ayudar al examen de los estados financieros. Otra revisión crítica de la existente
normas de auditoría se inició en 1974, cuando la AICPA creó sus primeras normas que cubren este
zona. Luego, 29 años después, el fiasco de Enron-Arthur Andersen de 2002 nos devolvió a 1973.
La cuestión del " debido cuidado profesional " ha pasado a primer plano en la comunidad de auditores como
como resultado de los principales escándalos financieros de EE. UU. y la mala gestión, que incluyen, entre otros,
Waste Management (1998), Enron (2001), Worldcom (2002), American Insurance Group (2005),
Lehman Brothers (2008), Bernard L. Madoff Securities LLC (2008), MF Global (2011), Anthem
Inc. (2015), Wells Fargo (2016) y otros. El escándalo EFCA de 1973 condujo al desarrollo de
fuerte regulación estatal y federal de las industrias de seguros y contabilidad creativa corporativa
en la industria aeroespacial, que brindó apoyo a la Ley de Prácticas Corruptas en el Extranjero (FCPA)
de 1977. Quizás hoy, la Ley Sarbanes-Oxley de 2002 (SOX) será un vívido recordatorio de la
importancia del debido cuidado profesional. SOX es un paquete de reforma importante, que exige la mayor
alcanzando los cambios que el Congreso ha impuesto al mundo empresarial desde la FCPA de 1977 y la
Ley de la Comisión de Bolsa y Valores (SEC) de 1934. Ejemplos de algunos de estos importantes
Los cambios incluyen la creación de una Junta de Supervisión Contable de Empresas Públicas , * así como la
aumento de las sanciones penales por infracciones de las leyes de valores. SOX se discutirá con más detalle
en el próximo capítulo.
* La PCAOB es una corporación sin fines de lucro instituida por el Congreso para supervisar las auditorías de las empresas públicas.
con el fin de proteger los intereses de los inversores y promover el interés público en la preparación de información,
informes de auditoría precisos e independientes. http://pcaobus.org/Pages/default.aspx.
Página 35
Auditoria financiera
La auditoría financiera abarca todas las actividades y responsabilidades relacionadas con la prestación
de una opinión sobre la equidad de los estados financieros. Las reglas básicas que rigen las opiniones de auditoría
indicar claramente que el alcance de una auditoría cubre todos los equipos y procedimientos utilizados en el procesamiento
datos significativos.
La auditoría financiera, tal como la lleva a cabo hoy el auditor independiente, fue impulsada por la legislación
en 1933 y 1934 que creó la SEC. Esta legislación ordenó que las empresas cuyos valores
fueron vendidos públicamente ser auditados anualmente por un Contador Público Autorizado (CPA). Los CPA, entonces, fue
encargado de dar fe de la imparcialidad de los estados financieros emitidos por empresas que informaron a
el segundo. La AICPA emitió en 1993 un documento denominado “ Informes sobre el control interno de una entidad
Estructura sobre la información financiera (Declaración sobre las normas para los encargos de certificación 2) ”para facili
Luego defina la importancia del control interno en el compromiso de certificación .
Dentro de la profesión de CPA en los Estados Unidos, se han establecido dos grupos de principios y estándares
han sido desarrollados que afectan la preparación de estados financieros por compañías que cotizan en bolsa
y los procedimientos para su examen de auditoría por parte de las firmas contables : contabilidad generalmente aceptada
Principios (GAAP) y normas de auditoría generalmente aceptadas (GAAS) .
GAAP establece pautas coherentes para la presentación de informes financieros por parte de los gerentes corporativos. C
parte del requisito de presentación de informes, también se establecen normas para el mantenimiento de
registros en los que se basan las declaraciones periódicas. Un auditor, emitiendo una opinión indicando que
los estados financieros se expresan de manera justa, estipula que los estados financieros se ajustan a los PCGA.
Estos principios contables han sido formulados y revisados periódicamente por organizaciones del sector privado.
nizaciones establecidas a tal efecto. El actual órgano de gobierno es la Contabilidad Financiera
Junta de Normas (FASB) . La implementación de GAAP es responsabilidad de la gerencia de
la entidad informante.
GAAS, el segundo grupo de normas, fue adoptado en 1949 por la AICPA para auditorías. Estas
Los estándares de auditoría cubren tres categorías:
◾ Las Normas Generales se relacionan con la competencia técnica y profesional, la independencia y la debida
cuidado profesional.
◾ Los estándares de trabajo de campo abarcan la planificación, la evaluación del control interno, la suficiencia de
materia probatoria o evidencia documental en la que se basan los hallazgos.
◾ Los Estándares de Informes estipulan el cumplimiento de todos los estándares de auditoría aceptados,
conformidad con el período contable anterior, idoneidad de la divulgación y, en el caso de que una
no se puede llegar a una opinión, el requisito de declarar la afirmación explícitamente.
GAAS proporciona pautas generales, pero no orientaciones específicas. La profesión ha complementado la
normas mediante la emisión de declaraciones de pronunciamientos autorizados sobre auditoría. El más completo
Uno de ellos es la serie SAS. Las publicaciones de SAS proporcionan una guía de procedimiento relacionada con muchos
aspectos de la auditoría. En 1985, la AICPA publicó una codificación del SAS No. 1-49. Hoy el
número de declaraciones excede 120.
Un tercer grupo de normas, denominadas Normas Internacionales de Información Financiera (NIIF) ,
ha sido creado recientemente por el Consejo de Normas Internacionales de Contabilidad (IASB) * para responder
al creciente entorno empresarial global y abordar la necesidad de comparar estados financieros
* El propósito del IASB es desarrollar un conjunto único de alta calidad, comprensible, ejecutable y global
estándares aceptados de información financiera basados en principios claramente articulados.
Página 36
preparado en diferentes países. El AICPA define las NIIF como el “conjunto de estándares contables desarrollados
operado por el IASB que se está convirtiendo en el estándar global para la preparación de empresas públicas
Estados financieros." Si bien muchas de las organizaciones globales ya han migrado a las NIIF, la
Estados Unidos aún tiene que hacerlo. Debido al tamaño de Estados Unidos y su significativa presencia global
Sin embargo, los US GAAP todavía tienen un impacto global significativo. Esto da como resultado las dos cuentas principal
esfuerzos de establecimiento de normas en el mundo: US GAAP e IFRS. Sin embargo, todas las naciones principales
ahora han establecido líneas de tiempo para converger o adoptar las normas IFRS en un futuro próximo.
Funciones de auditoría interna versus externa

Hay dos tipos de funciones de auditoría que existen en la actualidad. Tienen roles muy importantes para asegurar
la validez e integridad de los sistemas de información y contabilidad financiera. Son los internos y
funciones de auditoría externa.
Función de auditoría interna

El IIA define la auditoría interna (IA) como “una garantía y consultoría objetiva e independiente
actividad diseñada para agregar valor y mejorar las operaciones de una organización ". IA trae organizaciones
un enfoque sistemático y disciplinado para evaluar y mejorar su gestión , control y
procesos de gobernanza, así como para lograr sus metas y objetivos.
Los departamentos de AI suelen estar dirigidos por un director ejecutivo de auditoría (DEA) , que informa directamen
al Comité de Auditoría del Consejo de Administración . El CAE también reporta a la organización
ción del director general (CEO) . El propósito principal de la función de IA es asegurar que
los controles autorizados por la dirección se están aplicando de forma eficaz. La función IA, aunque no
obligatorio, existe en la mayoría de las empresas privadas o entidades corporativas, y en el gobierno (como la
gobiernos estatales, del condado y de la ciudad). La misión, el carácter y la fuerza de una función de AI
varían ampliamente dentro del estilo de los altos ejecutivos y las tradiciones de las empresas y organizaciones. ESO
Las auditorías son una de las áreas de apoyo para la AI.
El grupo de AI, si cuenta con el personal adecuado con los recursos, realiza un seguimiento durante todo el año
y prueba de las actividades de TI bajo el control de la organización. De particular interés para los privados
corporaciones es el procesamiento de datos y la generación de información de relevancia financiera o
materialidad .
Dado el gran papel que desempeña la dirección en la eficacia de una función de AI, su preocupación
con la confiabilidad e integridad de la información generada por computadora a partir de la cual se toman decisiones
hecho es fundamental. En organizaciones donde la gerencia muestra y demuestra preocupación por
controles internos, el papel de la AI crece en estatura. A medida que la función IA madura a través de la experiencia
experiencia, formación y desarrollo profesional, la función de auditoría externa y el público pueden confiar en
calidad del trabajo del auditor interno. Con una buena gestión y mejora continua de la AI
personal, el Comité de Auditoría del Consejo de Administración no duda en asignar revisiones adicionales,
responsabilidades de consulta y prueba para el auditor interno. Estas responsabilidades son a menudo
de alcance más amplio que los del auditor externo.
Dentro de los Estados Unidos, los auditores internos de agencias gubernamentales a menudo se reúnen para
reunirse e intercambiar experiencias a través de conferencias o foros. Por ejemplo, el Intergubernamental
Audit Forum es un ejemplo de un evento en el que se reúnen auditores de la ciudad, condado, estado y
entornos federales para intercambiar experiencias y proporcionar nueva información sobre tecnología de auditoría
niques y métodos. El IIA también celebra una conferencia nacional que atrae a una población de auditores
Página 37
de todo el mundo, tanto privados como gubernamentales, para compartir experiencias y discutir nuevas auditorías
métodos y técnicas.
Función de auditoría externa

La función de auditoría externa evalúa la confiabilidad y la validez de los controles de los sistemas en todos
formas. El objetivo principal de dicha evaluación es minimizar la cantidad de auditoría sustancial
realizar o probar las transacciones necesarias para emitir una opinión sobre los estados financieros.
Los auditores externos son proporcionados por firmas de contadores públicos y también existen en el gobierno.
Por ejemplo, la Oficina de Responsabilidad del Gobierno (GAO) se considera un revisor externo
porque puede examinar el trabajo de organizaciones federales y privadas donde los fondos federales están
previsto. Los Watchdogs of Congressional Spending brindan un servicio al contribuyente en informes:
dirigirse directamente al Congreso sobre cuestiones de mala gestión y controles deficientes. Curiosamente, en el extranjero
países, una Oficina del Inspector General o la Oficina del Auditor General dentro de ese país
prepara funciones similares. Además, la GAO ha sido un firme partidario de la Auditoría Internacional
Organización, que brinda capacitación y orientación en auditoría gubernamental a su auditoría internacional.
miembros que representan a gobiernos de todo el mundo.
Desde el punto de vista de una firma de contadores públicos, firmas como Deloitte, Ernst & Young,
PricewaterhouseCoopers y KPMG (en conjunto, los "Cuatro Grandes") proporcionan estos tipos
de los servicios de auditoría externa en todo el mundo. El auditor externo es responsable de probar la confiabilidad de
sistemas de TI del cliente y debe tener una combinación especial de habilidades y experiencia. Tal auditor
debe estar completamente familiarizado con la función de certificación de auditoría . La función de testificar abarca todos
actividades y responsabilidades asociadas con la emisión de una opinión de auditoría sobre la imparcialidad de la
Estados financieros. Además de las habilidades de contabilidad y auditoría involucradas en la realización del certificado
función, estos auditores externos también deben tener una experiencia sustancial en auditoría de TI. SOX ahora gobierna
su función y los límites de los servicios que se pueden ofrecer más allá de la auditoría.
¿Qué es la auditoría de TI?

Antes de definir qué es la auditoría de TI, expliquemos la diferencia entre SI y TI. Un es
representado por tres componentes (es decir, personas, procesos y TI), es la combinación de estrategia,
actividades administrativas y operativas involucradas en la gestión de la información. El componente de TI de un
SI involucra el hardware, software, comunicación y otras instalaciones necesarias para administrar (es decir,
introducir, almacenar, procesar, transmitir y emitir) dicha información. Consulte el Anexo 1.2.
El término auditoría, según ISACA, se refiere a la inspección y verificación formal para verificar
si se está siguiendo un estándar o un conjunto de pautas, los registros son precisos o la eficiencia y
se están cumpliendo los objetivos de eficacia. Al combinar ambas definiciones anteriores, la auditoría de TI puede
definido como el examen formal, independiente y objetivo de la infraestructura de TI de una organización
para determinar si las actividades (por ejemplo, procedimientos, controles, etc.) involucradas en la recolección, procesamie
almacenar, distribuir y usar información cumplir con las pautas, salvaguardar activos, mantener datos
integridad, y operar de manera efectiva y eficiente para lograr los objetivos de la organización . Auditoría de TI
proporciona una seguridad razonable (nunca absoluta) de que la información generada por las aplicaciones
dentro de la organización es precisa, completa y apoya la toma de decisiones efectiva y consistente
con la naturaleza y alcance del trabajo previamente acordado.
La auditoría de TI es necesaria para evaluar la idoneidad de los sistemas de aplicación para satisfacer las necesidades de
evaluar la idoneidad de los controles internos y asegurarse de que los activos controlados por esos sistemas
Página 38
Estos involucran estratégicos,

gerencial y operacional
actividades tradicionales trabajando
juntos hacia la reunión
ing, procesamiento, almacenamiento,
Información
distribuir y usar
sistemas
información
Personas integra hardware, software
Procesos
Ware, comunicación y
otras instalaciones para:
Ingresando Almacenamiento Procesando Transmitiendo Salida

datos datos datos datos datos
Figura 1.2 Sistemas de información versus tecnología de la información.
adecuadamente salvaguardado. En cuanto a los auditores de TI de hoy, sus conocimientos y habilidades avanzados
progresar de dos maneras. Una dirección es el crecimiento continuo y la habilidad en esta profesión, liderando el
camino en la investigación y el desarrollo de auditoría informática y el progreso de los
auditar trayectorias profesionales. La otra dirección implica capitalizar un conocimiento profundo de la organización
sistemas nacionales y avanzar hacia áreas profesionales más responsables en la dirección general. Hoy, incluso
en estos tiempos económicos, la demanda de auditores de TI calificados supera la oferta. Gobierno de TI
ha creado grandes oportunidades para el auditor de TI.
Aprender nuevas formas de auditoría es siempre una prioridad para los auditores de TI internos y externos. Más
los auditores quieren herramientas o metodologías de auditoría que les ayuden a realizar su tarea más rápidamente
y más fácil. Casi todas las grandes organizaciones o empresas tienen algún tipo de función de auditoría de TI o
tienda que involucra un departamento de auditoría interna. Hoy en día, las firmas "Cuatro Grandes" han designado
grupos especiales que se especializan en el campo de la auditoría de TI. Todos ellos cuentan con personal que realiza estas
Auditorías de TI. La mayoría de estos auditores de TI ayudan a los auditores financieros a establecer la exactitud de
estados financieros de las empresas en las que auditan. Otros se enfocan en proyectos especiales como
como seguridad de Internet que se ocupa de estudios de penetración, evaluaciones de firewall, puentes, enrutadores y
configuraciones de puerta de enlace, entre otras.
Hay dos grandes grupos de auditorías de TI, los cuales son esenciales para asegurar la continuidad
ued funcionamiento adecuado de IS. Estos son los siguientes:
◾ Auditoría general de controles informáticos. Examina los controles generales de TI ("controles generales" o
“ITGC”), incluidas las políticas y los procedimientos, que se relacionan con muchas aplicaciones y
puertos el funcionamiento eficaz de los controles de aplicación. Los controles generales cubren la infraestructura de T
estructura y servicios de soporte, incluidos todos los sistemas y aplicaciones. Controles generales
Página 39
comúnmente incluyen controles sobre (1) operaciones de SI; (2) seguridad de la información (ISec); y (3)
Gestión de control de cambios (CCM) (es decir, adquisición, cambio y mantenimiento de software del sistema
mantenimiento, cambio de programa y adquisición, desarrollo y mantenimiento del sistema de aplicación
maricón). Ejemplos de controles generales dentro de las operaciones de SI abordan actividades tales como datos
copias de seguridad y almacenamiento externo, supervisión de trabajos y seguimiento de excepciones hasta su finaliz
acceso al programador de trabajos, entre otros. Ejemplos de controles generales dentro de la dirección ISec
actividades tales como solicitudes de acceso y administración de cuentas de usuario, terminaciones de acceso y
seguridad física. Ejemplos de controles generales dentro de CCM pueden incluir solicitud de cambio
aprobaciones; actualizaciones de aplicaciones y bases de datos; y monitoreo de infraestructura de red, seguridad
ridad y gestión del cambio.
◾ Auditoría de controles de aplicaciones . Examina los controles de procesamiento específicos de la aplicación.
Los controles de aplicación también pueden denominarse "controles automatizados". Están preocupados
con la exactitud, integridad, vigencia y autorización de los datos capturados, ingresados,
procesado, almacenado, transmitido y reportado. Ejemplos de controles de aplicación incluyen verificación
medir la precisión matemática de los registros, validar la entrada de datos y realizar operaciones numéricas
controles de secuencia, entre otros. Es probable que los controles de aplicación sean efectivos cuando
los controles son efectivos.
Consulte el Anexo 1.3 para obtener una ilustración de los controles generales y de aplicación, y cómo deben
estar en su lugar para mitigar los riesgos y salvaguardar las aplicaciones. Observe en la exhibición que el
El sistema de aplicación está constantemente rodeado de riesgos. Los riesgos están representados en la exposición por explo
símbolos de sion. Estos riesgos pueden ser en forma de acceso no autorizado, pérdida o robo de equipos.
e información, apagado del sistema, etc. Los controles generales, que se muestran en los símbolos hexagonales,
también rodean la aplicación y proporcionan un “escudo protector” contra los riesgos. Por último, hay
la aplicación o los controles automatizados que residen dentro de la aplicación y proporcionan de primera mano
protección sobre la entrada, procesamiento y salida de la información.
Tendencias de auditoría de TI
La informática se ha vuelto indispensable para las actividades de organizaciones en todo el mundo. El control
El Marco de Objetivos para la Información y Tecnología Relacionada (COBIT) fue creado en 1995
por ISACA. COBIT, ahora en su quinta edición, enfatiza este punto y fundamenta la necesidad
para investigar, desarrollar, publicitar y promover un control de TI actualizado y aceptado internacionalmente
objetivos. En documentos anteriores, como el documento de debate de 1993 "Niveles mínimos de habilidad en
Tecnología de la información para contadores profesionales ”y su informe final de 1992“ The Impact
de Tecnología de la Información en la Profesión de Contabilidad ”, la Federación Internacional de
Contadores (IFAC) reconoce la necesidad de una mejor educación a nivel universitario para abordar el crecimiento
problemas y preocupaciones de control de TI.
Informes de robo de información, fraude informático, abuso de información y otros controles relacionados
Las preocupaciones se escuchan con mayor frecuencia en todo el mundo. Las organizaciones son más información-
consciente, la gente está dispersa debido a la descentralización, y las computadoras se utilizan más ampliamente en
todas las áreas del comercio. Debido a la rápida difusión de las tecnologías informáticas y la facilidad de información
accesibilidad de la información, auditores de TI informados y bien capacitados son necesarios para garantizar que más
Se implementan controles efectivos para mantener la integridad de los datos y administrar el acceso a la información.
La necesidad de mejores controles sobre TI se ha hecho eco en el pasado de estudios previos como el AICPA
Comité de Organizaciones Patrocinadoras de la Comisión Treadway (COSO); Internacional
Página 40
General
control S
Robo o "proteger
daño a proteger"
No autorizado
hardware
modificación de
sensible
información
Terminal de acceso Pérdida / robo de

proceso de nación información
Físico
seguridad
Implementar
tación de
solicitud
Supervisión/ cambios
seguimiento de Solicitud
trabajo (Aplicación o
excepciones automatizado
Sistema
control S) Cambio
choque
solicitud
aprobaciones
Fuera del sitio
almacenamiento
Cuenta
administración
Datos
apoyo No autorizado
divulgación de
Inapropiado confidencial
manual datos
intervención
No autorizado
Procesando
Figura 1.3 Relación entre controles informáticos generales y controles de aplicaciones.
Organización de Normalización (ISO) 17799 y 27000; la auditabilidad de los sistemas IIA y

Informe de control; Directrices para la seguridad de SI de la OCDE; el Consejo del Presidente de EE. UU.
Integridad y eficiencia en el plan de estudios de capacitación en auditoría informática; y el Nacional de los Estados Unidos
Estrategia para asegurar el ciberespacio lanzada en 2002; entre otros.
El Comité Ejecutivo de Servicios de Garantía de AICPA (ASEC) es responsable de actualizar y
mantener los Principios y Criterios de los Servicios de Confianza (TSPC) y crear un marco de
Principios y criterios para garantizar la integridad de la información. TSPC presenta criterios para
uso por parte de los profesionales cuando brindan certificación profesional o servicios de asesoramiento para evaluar los co
relevante para los siguientes principios:
◾ Seguridad : el sistema está protegido contra el acceso no autorizado (tanto físico como lógico).
◾ Disponibilidad : el sistema está disponible para su funcionamiento y uso según lo comprometido o acordado.
◾ Integridad del procesamiento : el procesamiento del sistema es completo, preciso, oportuno y autorizado.
◾ Confidencialidad : la información designada como confidencial se protege según se comprometió o acordó.
Página 41
◾ Privacidad : la información personal se recopila, utiliza, conserva, divulga y destruye en

conformidad con los compromisos en el aviso de privacidad de la entidad y con los criterios establecidos en
principios de privacidad generalmente aceptados emitidos por AICPA y CICA.
La teoría y las metodologías de la auditoría de TI se integran desde cinco áreas: una comprensión fundamental
reputación de negocios, auditoría tradicional, gestión de TI, ciencias del comportamiento y ciencias de TI.
La comprensión y el conocimiento empresarial son los pilares del proceso de auditoría. Tradicional
La auditoría contribuye al conocimiento de las prácticas de control interno y la filosofía de control general dentro de
una empresa comercial. La gestión de TI proporciona las metodologías necesarias para lograr
diseño e implementación de sistemas. La ciencia del comportamiento indica cuándo y por qué es probable que
fallar por los problemas de la gente. Las ciencias de TI contribuyen al conocimiento sobre la teoría del control y
Los modelos formales que subyacen a los diseños de hardware y software como base para mantener los datos.
integridad.
Desde que se formó ISACA ha habido una demanda creciente de personal bien capacitado y
profesionales calificados en auditoría de TI. La publicación The EDP Auditors Association: The First Twenty-Five
Years documenta las primeras luchas de la asociación y la evolución de las prácticas de auditoría de TI en este
campo.
El área de aseguramiento de la información también ha crecido y evolucionado. Estados Unidos en su paso
de la Ley de Investigación y Desarrollo de Seguridad Cibernética ha prometido casi mil millones de dólares para la
desarrollo de currículo, investigación y habilidades para futuros profesionales necesarios en este campo.
Aseguramiento de información
Las organizaciones confían cada vez más en las capacidades críticas de información electrónica digital para almacenar,
procesar y mover datos esenciales en la planificación, dirección, coordinación y ejecución de operaciones
ciones. Las amenazas potentes y sofisticadas pueden aprovechar las debilidades de seguridad en muchos de estos
sistemas. Subcontratar el desarrollo tecnológico a países que podrían tener terroristas en su
El personal de desarrollo genera especulaciones de que existe la posibilidad de que se implante un código que
Causar interrupciones, estragos, malversación de fondos, robos, etc. Éstas y otras debilidades que pueden
explotados se convierten en vulnerabilidades que pueden poner en peligro los componentes más sensibles de la información
capacidades de Sin embargo, podemos emplear defensas profundas en capas para reducir las vulnerabilidades y
disuadir, derrotar y recuperarse de una amplia gama de amenazas. Desde una perspectiva de aseguramiento de la informació
tivo, las capacidades que debemos defender se pueden ver en términos generales en términos de cuatro elementos principale
entornos informáticos locales, sus límites, las redes que los unen y sus
infraestructura
iniciativas. de apoyo. La estrategia nacional de EE. UU. Para asegurar el ciberespacio es una de esas
El término "garantía de la información" se define como integridad de la información (el nivel de confianza
y confianza que se puede depositar en la información) y disponibilidad del servicio. En todos los contextos, ya sea
negocio o gobierno, significa salvaguardar la recolección, almacenamiento, transmisión y uso
de información. El objetivo final del aseguramiento de la información es proteger a los usuarios, unidades de negocio,
y empresas de los efectos negativos de la corrupción de la información o la denegación de servicios. los
Departamento de Seguridad Nacional y Organizaciones de Apoyo como la Seguridad Nacional
Agencia (NSA), Oficina Federal de Investigaciones (FBI) y Agencia Central de Inteligencia (CIA)
todos han trabajado para apoyar este objetivo.
A medida que el Estado Islámico de la nación y sus infraestructuras críticas se unen (gobierno
y negocios), los puntos de entrada y exposición aumentan y, por lo tanto, aumentan los riesgos. La tecno-
avance lógico hacia comunicaciones de mayor ancho de banda y sistemas de conmutación avanzados
Página 42
ha reducido el número de líneas de comunicaciones y ha centralizado aún más la función de conmutación

ciones. Los datos de la encuesta indican que el mayor riesgo de estos cambios no está ampliamente reconocido.
Desde el 11 de septiembre, las organizaciones de defensa de EE. UU. Han realizado esfuerzos más coordinados, como el
Agencia de Sistemas de Información de Defensa para promulgar estándares para la Información de Defensa
Infraestructura y la Red de Información Global, que debería tener un impacto positivo en la información
garantía de seguridad que se extenderá más allá del Departamento de Defensa de EE. UU. y afectará a todos los segmentos d
la economía nacional. La NSA ha elaborado y elaborado estándares para el personal de seguridad de TI que
no solo impactan a las agencias federales sino también a las entidades corporativas que contratan servicios de TI en apoyo d
el Gobierno federal. NIST, por ejemplo, ha generado una guía de seguridad para los seguros médicos.
Cumplimiento de la Ley de Portabilidad y Responsabilidad que afecta a la profesión médica y a todos los
Poraciones / empresas al servicio del campo de la salud que manejan información médica. Un ejemplo similar
incluye los Estándares de seguridad de datos de la industria de tarjetas de pago (PCI DSS), mantenidos, administrados,
y promovido por el PCI Security Standards Council (Council) en todo el mundo. El Consejo fue
fundada en 2006 por las principales empresas de tarjetas de crédito, como American Express, Discover, JCB
International, MasterCard y Visa, Inc. Estas empresas comparten por igual en gobernanza, ejecución
ción y cumplimiento de los trabajos del Consejo. PCI DSS se refieren a los requisitos técnicos y operativos
aplicables específicamente a entidades que almacenan, procesan o transmiten datos de titulares de tarjetas, con el
intención de proteger dichos datos para reducir el fraude con tarjetas de crédito.
Necesidad de auditoría de TI
Inicialmente, auditoría de TI (anteriormente denominada procesamiento electrónico de datos [EDP], información informátic
sistemas [CIS] y auditoría de SI) evolucionó como una extensión de la auditoría tradicional. En ese momento, el
La necesidad de una auditoría de TI provino de varias direcciones:
◾ Los auditores se dieron cuenta de que las computadoras habían afectado su capacidad para realizar la certificación.
función.
◾ La gerencia corporativa y de procesamiento de información reconoció que las computadoras eran clave
recursos para competir en el entorno empresarial y similares a otros negocios valiosos
recurso dentro de la organización, y por lo tanto, la necesidad de control y auditabilidad fueron
crítico.
◾ Las asociaciones y organizaciones profesionales y las entidades gubernamentales reconocieron la necesidad de
Control de TI y auditabilidad.
Los primeros componentes de la auditoría de TI se extrajeron de varias áreas. Primero, auditoría tradicional
aporta conocimiento de las prácticas de control interno y la filosofía de control general. Otro
contribuyente fue la gestión de SI, que proporciona las metodologías necesarias para lograr
diseño e implementación de sistemas. El campo de la ciencia del comportamiento proporcionó tales preguntas
y análisis de cuándo y por qué es probable que IS falle debido a problemas de personas. Finalmente, el campo de
La ciencia de la computación aporta conocimientos sobre conceptos de control, disciplina, teoría y aspectos formales.
modelos que subyacen al diseño de hardware y software como base para mantener la validez de los datos, la confianza
capacidad e integridad.
La auditoría de TI se convirtió en una parte integral de la función de auditoría porque respalda la
juicio sobre la calidad de la información procesada por los sistemas informáticos. Auditores con TI
Las habilidades de auditoría se consideraban un recurso tecnológico para el personal de auditoría. El personal de auditoría a
los buscó en busca de asistencia técnica. El rol del auditor de TI evolucionó para garantizar que
Página 43
existen controles adecuados y adecuados. Por supuesto, la responsabilidad de garantizar que

los controles internos adecuados están en su lugar depende de la dirección. La función principal de la auditoría, excepto
en áreas de servicios de asesoría gerencial, es proporcionar una declaración de confiabilidad sobre si
Existen controles internos adecuados y fiables que funcionan de forma eficiente y eficaz.
conducta. El rol de la administración es asegurar y el rol de los auditores es asegurar.
Hay varios tipos de necesidades dentro de la auditoría de TI, incluidas las auditorías de TI organizacionales (gestión
control sobre TI), auditorías técnicas de TI (infraestructura, centros de datos, comunicación de datos) y
Auditorías de aplicaciones de TI (comerciales / financieras / operativas). También hay desarrollo / implementación
Auditorías de TI (especificaciones / requisitos, diseño, desarrollo y fases posteriores a la implementación), y
Auditorías de cumplimiento de TI que involucren estándares nacionales o internacionales.
Al auditar TI, la amplitud y profundidad de los conocimientos necesarios son amplios. Por ejemplo,
auditar TI implica:
◾ Aplicación de enfoques de auditoría orientados al riesgo

◾ Uso de herramientas y técnicas de auditoría asistidas por computadora
◾ Aplicación de estándares (nacionales o internacionales) como la ISO * para mejorar e implementar
mejorar los sistemas de calidad en el desarrollo de software y cumplir con los estándares de seguridad de TI
◾ Comprensión de los roles y expectativas comerciales en la auditoría de sistemas en desarrollo.
ment, así como la compra de paquetes de software y gestión de proyectos
◾ Evaluación de cuestiones de seguridad, confidencialidad, privacidad y disponibilidad de la información que
puede poner en riesgo a la organización
◾ Examen y verificación del cumplimiento de la organización con cualquier normativa legal relacionada con TI.
Problemas que pueden poner en peligro o poner en riesgo a la organización.
◾ Evaluación de ciclos de vida de desarrollo de sistemas complejos (SDLC) o nuevos desarrollos
técnicas de ment (es decir, creación de prototipos, informática del usuario final, sistemas rápidos o aplicaciones
desarrollo)
◾ Informar a la gerencia y realizar una revisión de seguimiento para asegurar las acciones tomadas
trabajo
La auditoría de los protocolos de comunicaciones y de TI generalmente involucra Internet, intranet,

extranet, intercambio electrónico de datos, servidores de clientes, redes de área local y amplia, comunicación de datos
comunicaciones, telecomunicaciones, tecnología inalámbrica, sistemas integrados de voz / datos / video, y
software y hardware que apoyan estos procesos y funciones. Algunas de las principales razones para
iniciar una auditoría de TI incluyen la mayor dependencia de la información por parte de las organizaciones, la
tecnología cambiante con nuevos riesgos asociados con dicha tecnología, y el apoyo necesario para
auditorías de estados financieros.
SOX también requiere la evaluación de controles internos y lo hace obligatorio para el registro de la SEC
istrants. Como parte del proceso para evaluar la efectividad de los controles internos sobre los
informes, la gerencia debe considerar los controles relacionados con el SI (incluidas las tecnologías) que
Apoyar los procesos financieros y comerciales relevantes. Estos controles se conocen como ITGC (o TI
controles generales). Como se mencionó anteriormente, los ITGC son procesos, actividades y / o procedimientos de TI
que se realizan dentro del entorno de TI y se relacionan con la forma en que las aplicaciones y los sistemas están
desarrollado, mantenido, administrado, protegido, accedido y operado. El cuadro 1.4 ilustra otros
razones principales para realizar auditorías de TI.
* Los ejemplos de normas ISO incluyen ISO / IEC 27002, ISO / IEC 27000 e ISO 17799.
Página 44
Apoyar el funcionamiento eficaz de

Evaluar el aumento de sofisticados y controles de aplicación
Programación "creativa"
Para controlar y monitorear lo significativo

Para respaldar las auditorías de estados financieros
crecimiento de los piratas informáticos corporativos, ya sea interno
o externo
Para evaluar la integridad y precisión de

información Para abordar los cambios rápidos
tecnología y los nuevos riesgos asociados
con tal tecnología
Evaluar la integridad de la información y
seguridad de los datos
Para identificar controles que pueden abordar
riesgos de TI específicos
Para controlar el fácil acceso a la organización
redes de oficina y personal remoto
ordenadores Para auditar grandes cantidades de datos
Figura 1.4 Principales razones para realizar una auditoría de TI.
Gobierno de TI
Ha habido muchos cambios en la forma en que las empresas abordan los problemas de TI, lo que ha dado como resultado un
centrarse en los conceptos de gobierno de TI. Directores generales, directores financieros , directores de operaciones
Los directores , directores de tecnología y directores de información acuerdan la fundación
principios de gobierno de TI, que se centran en la alineación estratégica entre TI y objetivos empresariales
tives. Esto, a su vez, crea cambios en la gestión operativa táctica y diaria de TI en
la organización.
La gobernanza de TI es el proceso mediante el cual se dirige y controla la TI de una empresa. Como definido
anteriormente, TI se refiere al hardware, software, comunicación y otras instalaciones utilizadas para ingresar,
almacenar, procesar, transmitir y generar datos en cualquier forma. Un gobierno de TI eficaz ayuda a garantizar
que TI respalde los objetivos comerciales, maximice la inversión comercial en TI y administre adecuadamente
Riesgos relacionados con las TI. El gobierno de TI también ayuda a garantizar el logro de factores críticos de éxito mediante
implementar de manera eficiente y efectiva información segura y confiable y tecnología aplicada.
Debido a que TI impacta en el funcionamiento de toda una organización, todos los miembros de la organización
debe tener un interés y un papel en la gobernanza de su uso y aplicación. Esta creciente conciencia
ha llevado a las organizaciones a reconocer que, si quieren aprovechar al máximo su inversión en TI y
proteger esa inversión, necesitan un proceso formal para gobernarla. Razones para implementar una TI
El programa de gobernanza incluye:
◾ Mayor dependencia de la información y de los sistemas que la entregan

◾ Mayor vulnerabilidad y un amplio espectro de amenazas
◾ Escala y costo de las inversiones actuales y futuras en información y SI
◾ Potencial de las tecnologías para cambiar drásticamente las organizaciones y las prácticas comerciales para
crear nuevas oportunidades y reducir costos
Página 45
Mientras estos factores sigan siendo parte del negocio, será necesario contar con una estructura eficaz e interdependiente.
sistemas de gobierno empresarial y de TI.
Una herramienta de gobierno de TI de estándar abierto que ayuda a los gerentes técnicos y no técnicos y
Los auditores comprenden y gestionan los riesgos asociados con la información y la TI relacionada es COBIT, desarrollo
a cargo del IT Governance Institute y la Information Systems Audit and Control Foundation.
COBIT es un marco integral de objetivos de control que ayuda a los auditores, gerentes y
los ejecutivos asumen responsabilidades fiduciarias, comprenden los sistemas de TI y deciden a qué nivel
de seguridad y control es adecuado. COBIT proporciona un conjunto internacional autorizado de
Prácticas de TI totalmente aceptadas para gerentes comerciales y auditores. COBIT se analiza en el Capítulo 3.
Papel del auditor de TI

El auditor que evalúa los sistemas complejos actuales debe tener habilidades técnicas altamente desarrolladas para
comprender los métodos en evolución de procesamiento de la información. Los sistemas contemporáneos conllevan riesgos
como plataformas no compatibles, nuevos métodos para penetrar la seguridad a través de la comunicación
redes (por ejemplo, Internet), y la rápida descentralización del procesamiento de la información con el
resultante pérdida de controles centralizados.
A medida que el uso de TI en las organizaciones continúa creciendo, la auditoría de sistemas computarizados debe ser
logrado sin muchas de las pautas establecidas para el esfuerzo de auditoría tradicional. En
Además, los nuevos usos de la TI introducen nuevos riesgos, que a su vez requieren nuevos controles. Los auditores de TI so
en una posición única para evaluar la relevancia de un sistema particular para la empresa en su conjunto.
Debido a esto, el auditor de TI a menudo juega un papel en la toma de decisiones de la alta dirección.
El rol del auditor de TI se puede examinar a través del proceso de gobierno de TI y el
estándares de práctica profesional para esta profesión. Como se mencionó anteriormente, el gobierno de TI es un
Participación organizacional en la gestión y revisión del uso de TI para lograr los objetivos.
y objetivos establecidos por la organización.
Auditor de TI como consejero

En el pasado, los usuarios han renunciado a la responsabilidad de controlar los sistemas informáticos, principalmente porque
de las barreras psicológicas que rodean a la computadora. Como resultado, hay pocos controles y
saldos, excepto el auditor de TI. Los auditores de TI deben desempeñar un papel activo en la asistencia a las organizaciones.
en el desarrollo de políticas, procedimientos, estándares y / o mejores prácticas para salvaguardar la información
mación, auditabilidad, control, pruebas, etc. Una buena política de seguridad de la información, por ejemplo, puede
incluir:
◾ Especificar las características de seguridad requeridas

◾ Definir "expectativas razonables" de privacidad con respecto a cuestiones como la supervisión de
ocupaciones
◾ Definir derechos y privilegios de acceso y proteger los activos de pérdidas, divulgaciones o daños
edades especificando pautas de uso aceptable para los usuarios
◾ Proporcionar pautas para comunicaciones externas (redes)
◾ Definición de responsabilidades de todos los usuarios
◾ Establecer confianza a través de una política de contraseñas eficaz
◾ Especificar procedimientos de recuperación
◾ Exigir que se registren las infracciones
Página 46
◾ Reconocer que los propietarios, custodios y clientes de la información deben informar

laridades y proteger su uso y difusión
◾ Proporcionar a los usuarios información de soporte
El Instituto SANS proporciona plantillas de políticas generales de seguridad de la información en su sitio web, que
puede descargarse y ser un excelente punto de partida para cualquier organización. Una buena seguridad informática
La política de ridad diferirá para cada organización, corporación o individuo dependiendo de la seguridad.
necesidades. Una política de seguridad de la información no garantizará la seguridad de un sistema ni hará que la red
completamente a salvo de posibles ataques desde el ciberespacio. Sin embargo, una política de seguridad, ayudada por
productos de seguridad eficaces y un plan de recuperación, pueden ayudar a dirigir las pérdidas potenciales a niveles
considerado "aceptable" y minimizar la filtración de información privada. El auditor de TI es parte
de un equipo institucional que ayuda a crear una gobernanza compartida sobre el uso, la aplicación y la garantía
ance sobre TI dentro de la organización.
Un personal de auditoría de TI en una gran empresa puede hacer una contribución importante al sistema informático
control persuadiendo a los grupos de usuarios para que insistan en una política de pruebas integrales para todos los sistemas
y todos los cambios en los sistemas existentes. Al revisar los resultados del caso base, los grupos de usuarios pueden control
precisión de sistemas nuevos o modificados mediante la realización de una función de control completa. Auditores
debe convencer a los usuarios y al personal de TI de la necesidad de un entorno de TI controlado.
Insistir en que todos los sistemas nuevos se revisen en puntos de control predefinidos en todo el sistema.
El ciclo de vida del desarrollo también puede mejorar el control de TI. La perspectiva de una revisión de auditoría debería
grupos de usuarios y de sistemas para definir sus objetivos y supuestos con mayor cuidado. Aquí también,
Los auditores de TI pueden extender sutilmente su influencia.
Auditor de TI como socio de la alta dirección

Aunque las funciones del auditor de TI de consejero y técnico calificado son vitales para el éxito de la empresa
operación, pueden ser irrelevantes si el auditor no ve la auditoría en relación con la organización
ción en su conjunto. Un sistema que parece estar bien controlado puede ser inconsistente con el funcionamiento de
un negocio.
Las decisiones relativas a la necesidad de un sistema pertenecían tradicionalmente a la dirección, pero porque
de una combinación de factores (principalmente la compleja tecnología de la computadora), sistema informático
las auditorías no se realizaron con éxito. Al asignar fondos para nuevos sistemas, la administración
ha tenido que confiar en el juicio del personal informático. Aunque sus elecciones de nuevos y más
Los sistemas
verdaderas informáticos
necesidades eficaces no
comerciales depueden tener fallas, el personal informático a menudo no ha cumplido con los
la organización.
La gerencia necesita el apoyo de un personal informático capacitado que comprenda las
requisitos, y los auditores de TI están en condiciones de proporcionar esa información. Pueden proporcionar
gestión con una evaluación independiente del efecto de las decisiones de TI en el negocio. Además de-
ción, el auditor de TI puede verificar que se hayan considerado todas las alternativas para un proyecto dado, todos los riesgo
han sido evaluados con precisión, las soluciones técnicas de hardware y software son correctas, negocios
se satisfarán las necesidades y los costos serán razonables.
Auditor de TI como investigador

Como resultado del aumento de la legislación y el uso de pruebas informáticas en los tribunales, la capacidad
capturar y documentar información generada por computadora relacionada con la actividad delictiva es fundamental
a efectos de enjuiciamiento. El conocimiento y el uso de herramientas y técnicas asistidas por computadora en
Página 47
realizar trabajo de soporte forense ha brindado nuevas oportunidades para el auditor de TI, seguridad de TI
personal, y aquellos dentro de la aplicación de la ley y la investigación. Para el profesional de auditoría de TI,
La informática forense es un campo en desarrollo apasionante. El auditor de TI puede trabajar en el campo de la
informática forense o trabajar codo a codo con un especialista en informática forense, proporcionando información sobre un
sistema o red particular. Los especialistas pueden hacer preguntas a los profesionales de auditoría de TI sobre
acceder al sistema y obtener respuestas más rápido que tener que investigar y resolver todo
en su propia. Aunque el especialista está altamente capacitado y puede adaptarse a casi cualquier sistema o
plataforma, la colaboración puede facilitar el trabajo del especialista forense y del profesional de TI
y más eficiente.
Desde su nacimiento a principios de la década de 1970, la informática forense ha evolucionado continuamente hacia lo q
ahora un campo muy grande. Las nuevas tecnologías y las mejoras en los protocolos permiten a los ingenieros
y desarrolladores para crear hardware, software y herramientas más estables y robustos para que el especialista
uso en investigaciones criminales relacionadas con la informática. A medida que las computadoras se vuelven más avanzada
abundante, también lo hacen las actividades delictivas. Por lo tanto, el nicho de la informática forense también está en consta
progresión junto con los avances tecnológicos de las computadoras.
Auditoría de TI: la profesión

Con la aprobación de la Ley de Seguridad Nacional, la Ley Patriota y SOX, el papel del auditor
(interno y externo) es más crítico para la verificación y validación de la infraestructura financiera
ture. La profesión de auditoría de TI puede proporcionar a una persona exposición a la forma en que la información
fluye dentro de una organización y dan a sus miembros la capacidad de evaluar su validez, confiabilidad y
seguridad. La auditoría de TI involucra personas, tecnología, operaciones y sistemas. Es una dinámica
y una profesión desafiante con un futuro que trae crecimiento a nuevas áreas como la seguridad de TI
y la informática forense, por nombrar algunos.
Hoy en día, los auditores de TI interactúan con gerentes, usuarios y técnicos de todas las áreas de la mayoría de organiza
nizaciones. Deben tener habilidades interpersonales para interactuar con múltiples niveles de personal y
Habilidades técnicas para comprender la variedad de tecnología utilizada en la actividad de procesamiento de información.
especialmente la tecnología utilizada para generar y / o procesar la información financiera de la empresa
ción (por ejemplo, estados financieros, etc.). El auditor de TI también debe comprender y ser
familiarizado con el entorno operativo para evaluar la eficacia del control interno
estructura . Finalmente, el auditor de TI debe comprender las complejidades tecnológicas de los
sistemas futuros y el impacto que tienen en las operaciones y decisiones en todos los niveles.
La auditoría de TI es una profesión relativamente nueva y las oportunidades de empleo están presentes en todos los sect
tors de la industria privada, la contabilidad pública y el gobierno en todo el mundo. Una profesión es más que
solo una ocupación. Una profesión tiene ciertas características especiales, incluido un cuerpo común de
conocimiento, certificación, educación continua, asociaciones profesionales y estándares éticos,
y currículo educativo.
Un cuerpo común de conocimientos

Desde 1975, se han realizado varios estudios que identifican un cuerpo común de conocimientos para la
Profesión de auditoría de TI. Un cuerpo común de conocimientos consta de áreas claramente identificadas en las que
una persona debe alcanzar un nivel específico de comprensión y competencia necesaria para
práctica dentro de la profesión. Estas áreas se clasifican en áreas centrales. Organizaciones como
ya que ISACA, AICPA, IIA, CICA, ISSA, InfoSec y otros alrededor del mundo han emitido importantes
Página 48
estudios y artículos sobre el tema de los conocimientos, habilidades y habilidades necesarias para auditar computadoras
sistemas. Los estudiantes, especialmente aquellos con especialización en negocios e informática, reciben un grado de
capacitación de nivel básico en (1) conceptos y prácticas de auditoría; (2) conceptos y prácticas de gestión;
(3) sistemas informáticos, telecomunicaciones, operaciones y software; (4) información de la computadora
técnicas de procesamiento; y (5) comprensión del negocio a escala local e internacional. Estas
son algunas de las principales áreas de competencia identificadas por los diversos estudios independientes para
la persona que ingresa al campo de auditoría, control y seguridad de TI.
Certificación
La certificación es un componente vital de una profesión. Mientras se prepara para ingresar a su profesión,
Ya sea que se trate de contabilidad, SI u otros campos comerciales, la certificación será la medida de su nivel.
de conocimientos, habilidades y habilidades en la profesión. Por ejemplo, la consecución de la designación de CPA
La formación es un hito importante en la carrera del contador en ejercicio. En auditoría de TI, el certificado
Auditor de sistemas de información (CISA) es uno de los principales niveles de reconocimiento y consecución.
Existen ciertos requisitos para que los candidatos obtengan la certificación CISA, tales como:
◾ Aprobar un riguroso examen escrito

◾ Evidenciar un mínimo de 5 años de trabajo profesional de auditoría, control o seguridad de SI
experiencia
◾ Cumplir con el Código de Ética Profesional de ISACA y la Auditoría de Sistemas de Información
Estándares adoptados por ISACA
◾ Aceptar cumplir con la Política de educación continua de CISA
El examen CISA cubre áreas (o dominios) dentro del proceso de auditoría de SI; gobernancia
y gestión de TI; Adquisición, desarrollo e implementación de SI; Operaciones de SI, mantenimiento
gestión de finanzas y servicios; y la protección de los activos de información. Así, la educación universitaria
catión juega un papel importante al proporcionar las bases para el proceso de certificación.
Otras licencias y certificaciones relevantes para el auditor de TI incluyen las siguientes: CPA, certificado
Contador colegiado (CA), Auditor interno certificado (CIA), Profesional informático certificado
(CCP), Gerente Financiero Gubernamental Certificado (CGFM), Sistemas de Información Certificados
Security Professional (CISSP), Certified Information Security Manager (CISM), Certified in
Control de riesgos y sistemas de información (CRISC), tecnología de información certificada por AICPA
Profesional (CITP) y examinador certificado de fraude (CFE).
La certificación es importante y una medida del logro de habilidades dentro de la profesión. Logro
de más de una certificación mejorará sus conocimientos, habilidades y habilidades dentro de la auditoría
dominio. La competencia en la aplicación de habilidades proviene de la experiencia y la educación continua. los
Los cambios dinámicos en los negocios (comercio), TI y eventos mundiales continúan dando forma al futuro para
esta apasionante profesión.
Educación continua
La certificación requiere educación continua para que aquellos que están certificados mantengan un nivel de
competencia y continuar su certificación. La educación continua es un elemento importante para
crecimiento profesional. A medida que los graduados ingresen a su profesión, encontrarán que su educación académica
es la base para el desarrollo continuo de conocimientos, destrezas y habilidades que mejoran la carrera.
Existe un requisito de educación continua para apoyar el programa CISA. El auditor de TI del
Página 49
futuro se enfrentará constantemente a cambios con respecto a los sistemas existentes y la dinámica del medio ambiente
ambiente (es decir, reorganización, nueva tecnología, cambio operativo y requisitos cambiantes).
La amplitud y profundidad de los conocimientos necesarios para auditar TI es extensa. Por ejemplo, auditoría de TI
implica la aplicación de enfoques de auditoría orientados al riesgo; el uso de herramientas de auditoría asistidas por computa
y técnicas (por ejemplo, EnCase, CaseWare, Idea, ACL, Guardant, eTrust, CA-Examine, etc.); la
aplicación de normas nacionales o internacionales (es decir, ISO 9000/3, ISO 17799, ISO 27000 y
enmiendas relacionadas para mejorar e implementar sistemas de calidad en el desarrollo de software); la
Auditoría de sistemas en desarrollo que involucran SDLC complejos o nuevas técnicas de desarrollo.
(por ejemplo, creación de prototipos, informática de usuario final, desarrollo rápido de sistemas, etc.); y la auditoría de empr
tecnologías plex que implican el intercambio electrónico de datos, servidores de clientes, redes de área local y amplia,
comunicaciones de datos, telecomunicaciones y sistemas integrados de voz / datos / video.
Dado que el entorno organizacional en el que opera el auditor de TI es dinámico,
Es importante que los nuevos desarrollos en la profesión se entiendan para que puedan ser apropiados
aplicado correctamente. Por lo tanto, el requisito de educación continua ayuda al CISA a obtener nuevos conocimientos.
y habilidades para brindar la opinión profesional más informada. Los cursos y programas de formación son
ofrecidos por una amplia variedad de asociaciones y organizaciones para ayudar a mantener los
habilidades que necesitan para seguir mejorando y evolucionando. Los métodos para recibir dicha formación pueden
incluso ser global con video teleconferencia y teletrabajo y con Internet jugando un
papel principal en la impartición de formación.
Asociaciones profesionales y estándares éticos

Como gerente en cualquier nivel, uno debe recordar que los auditores, ya sean internos o externos, tienen
estándares de práctica que deben seguir. Al igual que los profesionales de TI, los auditores pueden pertenecer a uno o
más asociaciones profesionales y tener un código de ética y estándares profesionales de prácticas y
orientación que les ayude a realizar sus revisiones y auditorías. Si se ve que no funcionan
Al llevar su trabajo a "estándares de práctica" para su profesión, saben que podrían estar abiertos a una
demanda potencial o incluso "descertificado". Algunas de las organizaciones que produjeron tales estándares de
práctica son AICPA, IIA, IFAC, CICA, GAO e ISACA.
ISACA, creada en 1969, es el líder en gobernanza, aseguramiento, así como seguridad y con-
Trol asociación profesional de hoy. ISACA:
◾ proporciona
premia la gobernanza, la gestión
conocimiento de riesgos
y educación de TI
en áreas y elaseguramiento
como cumplimiento.de SI, seguridad de la información,
◾ ofrece certificaciones / designaciones mundialmente conocidas, como CISA, CISM, Certificado en el
Gobernanza de TI empresarial (CGEIT) y Certificado en Riesgo y CRISC.
◾ desarrolla y actualiza con frecuencia estándares internacionales de auditoría y control de SI, tales como,
el estándar COBIT. COBIT asiste tanto a los auditores de TI como a la gerencia de TI, a realizar
sus deberes y responsabilidades diarios en las áreas de aseguramiento, seguridad, riesgo y control, y
entregar valor a la empresa.
Para actuar como auditor, uno debe tener un alto nivel de ética moral. El término auditor es latino para
uno que escucha quejas y toma decisiones o actúa como un juez. Para actuar como juez, uno definitivamente
debe ser moralmente ético o frustrará el propósito. La ética es una base muy importante para nuestra cultura
como un todo. Si el auditor pierde el favor en esta área, es casi imposible recuperar la confianza del auditor.
tor una vez tuvo con la gerencia de auditoría y los auditados. Si un auditor es ético al principio
o no, todos deben comenzar con la misma cantidad de confianza y buen favor del cliente o
Página 50
auditado. Si el vínculo no se rompe, el auditor establece un buen nombre como alguien que puede
confiado con material sensible.
En la economía mundial actual, la confianza es una palabra inaudita. Nadie puede confiar en nadie estos días
y por esta razón es imperativo que la alta ética esté en la parte superior de la lista de temas del gerente para
cubrir con nuevos equipos de auditoría. Los tiempos están cambiando y también los clientes que solicitan servicios de audito
La mayoría de los gerentes afirmarán que aprecian este aspecto llamado ética porque los distingue
de otros sin él.
Por ejemplo, digamos que un presupuesto requiere varias horas. No es ético dejar horas sin
trabajó. Tampoco es ético pasar por alto algo durante la auditoría porque el cliente dice que no es
importante. Existe una delgada línea entre lo ético y lo legal. Algo puede ser éticamente
incorrecto pero aún legal. Sin embargo, dicho esto, algunas cosas inicialmente se pensó que no eran éticas.
convertirse en ilegal con el tiempo. Si hay una población suficientemente grande que se opone a algo éticamente
incorrecto, verá una legislación introducida para hacerla ilegal.
Cuando los auditores de TI obtienen su certificación CISA, también se suscriben a un Código de
Ética. Este código se aplica no solo a la conducta profesional sino también a la conducta personal de
Auditores de TI. El código en realidad no entra en conflicto con los códigos de ética de otras auditorías / aseguramiento
dominios relacionados (por ejemplo, IIA, AICPA, etc.). Requiere que se cumplan los estándares de ISACA,
se mantiene la confidencialidad, se informa sobre cualquier actividad ilegal o inapropiada, la competencia del auditor
se mantiene, se utiliza el debido cuidado en el curso de la auditoría, los resultados del trabajo de auditoría se comunican
se mantienen altos estándares de conducta y carácter.
Currículos educativos
La auditoría de TI es una profesión con conducta, objetivos y cualidades que se caracterizan por
amplios estándares técnicos y éticos. Requiere conocimientos especializados y, a menudo, largos e intensos.
preparación académica siva. La mayoría de las sociedades profesionales de contabilidad, auditoría y TI creen que
Las mejoras en la investigación y la educación proporcionarán sin duda una "teoría teórica mejor desarrollada
y base de conocimientos empíricos para la función de auditoría de TI ". Sienten que se debe poner énfasis
sobre la educación obtenida a nivel universitario.
Las comunidades académicas tanto en los Estados Unidos como en el extranjero han comenzado a incorporar
porciones del cuerpo común de conocimientos y los dominios del examen CISA en cursos
enseñado a nivel universitario. Varios estudios recientes indican el crecimiento de los cursos de auditoría informática
emergente
Varias en los planes dehan
universidades estudio universitarios
desarrollado planes de
de todo el mundo.
estudio adaptados para apoyar la profesión de auditoría de TI.
Aunque los planes de estudio de estas universidades evolucionan constantemente, actualmente existen en instituciones
como la Universidad de Bentley (Massachusetts), la Universidad Estatal de Bowling Green (Ohio), California
Universidad Politécnica del Estado, Universidad de Mississippi, Universidad de Texas, Estado de Georgia
Universidad, Universidad de Maryland, Universidad de Tennessee, Universidad Tecnológica Nacional
(Argentina), Universidad de Columbia Británica (Canadá), Universidad de York (Canadá) y Hong
Kong University of Science and Technology, entre otros. Los graduados de estos programas
si tienen 1 año de experiencia laboral para obtener la certificación CISA.
Un modelo de plan de estudios para la educación de pregrado y posgrado en educación en auditoría de SI y TI
se emitió inicialmente en marzo de 1998 y se actualizó en 2004, 2009 y 2011 por Auditoría de SI y
Asociación y Fundación de Control. El propósito del Modelo es proporcionar colegios, universidades
vínculos, y / o instituciones educativas las herramientas necesarias para educar a los estudiantes y prepararlos
para ingresar a la profesión de auditoría de TI. La educación a través del modelo se centra en el curso fundamental
componentes de auditoría y control de TI, así como también se mantiene al día con el rápido ritmo de la tecnología
Página 51
cambio. Dicha educación también está en línea con los eventos recientes, las regulaciones gubernamentales y los cambios en
procesos de negocio, todos los cuales han afectado el papel de la auditoría de TI y las metodologías utilizadas por
Auditores de TI.
Perfil de auditor de TI: experiencia y habilidades

La experiencia en auditoría de TI es imprescindible. Nada en este mundo se puede comparar con el trabajo real,
experiencias del mundo real. La teoría también es valiosa y, en su mayor parte, un auditor de TI debe confiar en
teoría para progresar a través de una auditoría. Por ejemplo, si los auditores de TI desean demostrar su competencia
mitment y nivel de conocimiento del campo, pueden seleccionar un área para ser probado. Varios profesionales
Existen certificaciones nacionales que pueden beneficiar al auditor. En el área de auditoría de TI, por ejemplo, para aprobar
Examen CISA, uno debe conocer, comprender y ser capaz de aplicar la teoría de la auditoría de TI moderna a
todas las preguntas del examen planteadas. Existen otras licencias y certificaciones relevantes, como se mencionó anteriorm
que puede ser muy útil para la carrera y los planes futuros de un auditor de TI.
La comprensión de la teoría es definitivamente esencial para un auditor de TI exitoso. Sin embargo, el-
ory solo podemos llevar uno hasta ahora. Este libro de texto y otros disponibles deben verse como una guía. En
En este campo, debido a la complejidad y situación de la tecnología, llega un momento en que un auditor de TI
tiene que confiar en la experiencia para afrontar una situación nueva, nunca antes encontrada. Experiencia en el
campo es una ventaja definitiva, pero tener experiencia en una variedad de otros campos a veces puede ser más
beneficioso. Por ejemplo, un gerente de auditoría de TI que trabaja para una firma de contabilidad pública Big Four es
estará expuesto a una amplia variedad de situaciones y escenarios de auditoría de TI. Tal experiencia
ayudar a ampliar horizontes y ampliar los conocimientos en el campo de la auditoría de TI. Otro ejemplo sería un
Supervisor de Auditoría Interna que ha realizado auditorías de cumplimiento y centradas en el riesgo para todos los departam
mentos dentro de una organización. Una experiencia tan amplia no es más que una ventaja, y probablemente permitirá
el auditor para agregar valor significativo y superior a las operaciones de la organización.
La entrada directa a la profesión, como es la situación actual, puede cambiar con los requisitos del nivel de entrada.
mentos, incluida la experiencia en procesos comerciales, sistemas y tecnología, así como
Conocimiento de la teoría general de auditoría complementado con experiencia práctica. Además, TI
Los auditores pueden requerir experiencia industrial específica, como banca, telecomunicaciones, transporte
tación, o finanzas y seguros para abordar adecuadamente el negocio / tecnología específicos de la industria
cuestiones. Este libro proporciona información actual y enfoques de este complejo campo, que puede
ayudar a los practicantes y aquellos que quieran aprender más.
La experiencia viene con tiempo y perseverancia, como es bien sabido, pero los auditores no deben limitar
ellos mismos a una sola industria, software o sistema operativo. Deberían desafiarse a sí mismos
y ampliar sus horizontes con una multitud de exposiciones en diferentes entornos, si es posible.
Cuanto más amplio y completo sea el auditor de TI, mayores serán las posibilidades de una carrera de auditoría exitosa.
Además de la experiencia, los auditores de TI eficaces deben poseer una variedad de habilidades que permitan
ellos para agregar valor a sus organizaciones o clientes. La mejor experiencia técnica o formación.
no necesariamente prepara completamente a los auditores para las habilidades de comunicación y negociación que son
requerido para el éxito.
Muchas de las habilidades no técnicas o complementarias están relacionadas con la recopilación de información.
de y, de importancia comparable, presentar información a las personas. Como tal, estos suplementos
Las habilidades mentales son fácilmente transferibles a otras disciplinas, por ejemplo, finanzas, administración y
márketing. El producto final que crean los auditores es un informe de auditoría. Si la información dentro de la auditoría
el informe no se entrega de manera efectiva y eficiente a través de sólidas habilidades de comunicación oral y escrita,
todo el valor acumulado del proceso de auditoría podría potencialmente perderse.
Página 52
Tener un conjunto diverso de habilidades complementarias o "blandas" nunca está de más cuando uno está trabajando co
auditado . Por ejemplo, un auditor senior de TI estaba realizando recientemente una auditoría en la que se enfrentó
con un cliente / auditado que no fue muy cooperativo. Durante el proceso de interrogatorio, el personal superior de TI
El auditor estableció una relación con el cliente mediante el uso de habilidades interpersonales o "habilidades blandas". El p
auditor no es una tarea fácil cuando se nos pide que revisemos, cuestionemos y evaluemos el trabajo de otros.
Muchas veces, el auditado debe tener una comprensión clara de nuestro rol y que el enfoque del auditor es
no ser crítico con el individuo sino con las políticas, procedimientos y procesos de la organización. los
Los objetivos de auditoría se centran tanto en las metas como en los objetivos de la organización.
Oportunidades profesionales
Hay una serie de oportunidades profesionales disponibles para la persona que busca una oportunidad en
Auditoría de TI. Para el graduado universitario con el conocimiento, las habilidades y las habilidades de nivel de entrada ade
esta carrera ofrece muchos caminos para el crecimiento y el desarrollo. Además, a medida que se desarrolla una carrera y
progresa, la auditoría de TI también puede proporcionar movilidad a otras áreas. Los auditores de TI de hoy están empleados
por empresas de contabilidad pública, industrias privadas, empresas de consultoría de gestión y el gobierno.
Empresas de Contaduría Pública

Las firmas de contadores públicos ofrecen a las personas la oportunidad de ingresar al campo de la auditoría de TI. A pesar d
Estas empresas pueden requerir que dichas personas comiencen sus carreras en auditorías financieras para ganar experiencia
experiencia en la comprensión de las metodologías de auditoría de la organización, después de la experiencia inicial de audit
individuo que expresa interés en una especialización en particular (por ejemplo, forense, seguridad, etc.) será
transferido a dicha especialidad para una mayor formación y desarrollo profesional. Muchos que han tomado
esta trayectoria profesional ha sido exitosa y varios se han convertido en socios, directores o directores
dentro de la firma. Las fuentes principales para la mayoría de las firmas de contadores públicos son el reclutamiento univers
desarrollo interior. Sin embargo, no es raro que una empresa contrate personal externo para
experiencia (por ejemplo, informática forense, telecomunicaciones, sistemas de bases de datos, etc.).
Industria privada
Al igual que las empresas de contabilidad pública, la industria privada ofrece puestos profesionales de auditoría de TI de niv
Además, los auditores de TI adquieren experiencia en áreas más especializadas (es decir, telecomunicaciones, sistemas
software y diseño de sistemas), lo que puede convertirlos en candidatos para operaciones de TI, análisis forense de TI,
y puestos de seguridad de TI. Muchos directores ejecutivos ven la experiencia de auditoría como una función de capacitació
ción. El auditor de TI tiene fortalezas particulares de formación, experiencia práctica
con SI corporativo y comprensión de la toma de decisiones ejecutivas. Algunas empresas han hecho un
distinción entre auditores de TI y auditores operativos y financieros. Otros requieren todos los internos
que los auditores sean capaces de auditar los sistemas de TI. Fuentes de personal para la función de auditoría de TI
dentro de una empresa generalmente puede provenir de reclutamiento universitario, transferencias internas, promociones,
y / o contratación externa.
Empresas de consultoría de gestión

Otra área de oportunidad para el personal de auditoría de TI es la consultoría de gestión. Esta área de carrera es
generalmente disponible para auditores de TI con varios años de experiencia. Muchos consultoría de gestión
Página 53
prácticas, especialmente aquellas que brindan servicios en el entorno informático de SI, contratan experimentados
Auditores de TI. Esta trayectoria profesional permite a estos candidatos utilizar sus conocimientos, habilidades y
habilidades para diagnosticar una serie de problemas de información de gestión y de la computadora y luego ayudar
la organización en la implementación de las soluciones. Los recursos habituales para tales puestos se esperan
personal experimentado de firmas contables contables públicas, industrias privadas y el gobierno. ESO
La ciencia forense es otra área en crecimiento en los servicios de consultoría de gestión.
Gobierno
El gobierno ofrece otra vía para que uno adquiera experiencia en auditoría de TI. En los Estados Unidos,
Los gobiernos federal, estatal, del condado y de la ciudad emplean personal para llevar a cabo respuestas relacionadas con au
posibilidades. Las organizaciones federales como la NSA, el FBI, el Departamento de Justicia y la CIA emplean
personal que tiene experiencia en auditoría de TI, experiencia en seguridad informática y experiencia forense de TI
ence. Los gobiernos de todo el mundo también emplean personal para realizar auditorías de TI.
Los puestos gubernamentales ofrecen capacitación y experiencia al personal responsable de realizar
Funciones de auditoría de TI. Las fuentes de los auditores de TI del gobierno son reclutas universitarios y empleados que bu
promoción interna o transferencia. Hay ocasiones en las que se pueden contratar recursos experimentados de
el exterior también.
Conclusión
Las operaciones comerciales están cambiando a un ritmo rápido debido a la rápida mejora continua de la tecnología.
nología. La tecnología ha impactado varias áreas del entorno empresarial, incluido el uso y
procesamiento de información, procesos de control existentes y cómo se realizan las auditorías para sacar conclusiones
siones con respecto a la eficacia operativa o del sistema, la eficiencia y la integridad de los informes. También se observa
que la tecnología cambia constantemente e identifica formas de dar forma a los entornos de TI actuales en el
organización. Se describieron varias tecnologías recientes que han tenido y ciertamente continuarán
para revolucionar las organizaciones, en particular la forma en que se hacen negocios y la dinámica del lugar de trabajo.
Debido a los principales fraudes y escándalos corporativos y contables, la profesión de auditoría, tanto
funciones internas y externas, ahora mira seriamente la falta de controles en la información de la computadora
sistemas de mation. Dentro de la auditoría financiera, por ejemplo, existen principios y estándares que
gobiernan la profesión de contador público autorizado en los Estados Unidos (es decir, GAAP y GAAS). Estos buscan preci
preparación de estados financieros, así como procedimientos efectivos para sus exámenes de auditoría. UN
diferentes tipos de auditoría, la auditoría de TI, se ha convertido en una parte integral de la función de auditoría porque
apoya el juicio del auditor sobre la calidad de la información procesada por el sistema informático
tems. La auditoría de TI proporciona una seguridad razonable (nunca absoluta) de que la información generada
por aplicaciones dentro de la organización es precisa, completa y apoya la toma de decisiones efectiva
en consonancia con la naturaleza y alcance acordados. Hay dos grandes grupos de auditorías de TI (es decir,
Auditoría General de Controles Computacionales y Auditoría de Controles de Aplicación), ambos esenciales para asegurar l
funcionamiento adecuado continuado de IS.
Para el auditor de TI, la necesidad de auditoría sigue siendo crítica y sigue siendo exigente.
Hay muchos desafíos por delante; todos deben trabajar juntos para diseñar, implementar y proteger
velar por la integración de tecnologías nuevas y existentes en el lugar de trabajo. Dado el papel variado
sombreros que los auditores de TI pueden usar, deben mantenerse actualizados con las revisiones y cambios en las leyes exis
que rigen el uso de computadoras e Internet. Los auditores de TI pueden proporcionar influencia para ayudar a las organizac
Las organizaciones entienden los riesgos que enfrentan y las posibles consecuencias.
Página 54
Preguntas de revisión
1. La tecnología ha impactado el entorno empresarial en tres áreas. Resume esas áreas.
2. Diferenciar entre auditores internos y externos en términos de sus roles y responsabilidades.
3. ¿Cómo se define la auditoría de TI?
4. Auditoría general de controles informáticos y controles de aplicaciones La auditoría son los dos grandes grupos:
ings de auditorías de TI. Resuma ambas auditorías y proporcione ejemplos específicos que respalden la
controles evaluados dentro de cada tipo de auditoría.
5. El TSPC, mantenido por la ASEC de AICPA, presenta criterios para que los utilicen los profesionales cuando
prestación de servicios profesionales de certificación o asesoramiento para evaluar los controles pertinentes a cinco p
principios. Describe con tus propias palabras estos principios.
6. Explique qué es la garantía de la información.
7. Una de las funciones del auditor de TI es actuar como consejero de las organizaciones. Como consejero,
Los auditores de TI pueden ayudar a las organizaciones a desarrollar políticas, procedimientos, estándares y / o
mejores prácticas, como una política de seguridad de la información. Usando las características de un bien
política de seguridad de la información enumerada en el capítulo, desarrollar cinco políticas de seguridad de la inform
que compartirías con tu cliente.
8. Explique por qué la auditoría de TI se considera una profesión. Describa los requisitos para que los candidatos
obtener la certificación CISA.
9. ¿Qué es ISACA y cómo ayuda a la profesión de auditoría de TI?
10. ¿Dónde están las oportunidades profesionales actuales para el auditor de TI? Busque en Internet e identifique
Indique al menos un perfil / descripción de trabajo para cada oportunidad profesional identificada anteriormente. Para
perfil de trabajo identificado, enumere lo siguiente en forma de tabla:
a. Descripción del trabajo
segundo. Deberes, tareas y responsabilidades requeridas
C. Requisitos mínimos de trabajo (o calificaciones)
re. Requisitos mínimos de educación y / o certificación
mi. Conocimientos, destrezas y habilidades requeridas, etc.
Ejercicios
1. Después de leer este capítulo, debe sentirse cómodo con las funciones y responsabilidades generales
capacidades de un auditor de TI.
a. Describa con sus propias palabras qué hacen los auditores de TI.
segundo. ¿Por qué deberían formar parte del equipo de auditoría general al realizar la evaluación financiera anual?
auditoría de un cliente?
2. Enumere cinco sitios web a los que puede acceder para obtener información sobre:
a. Auditoría de TI
segundo. Problemas de privacidad y seguridad de TI
3. Visite los sitios web de cuatro organizaciones de auditoría externa: dos privadas y dos gubernamentales
sitios. Proporcione un resumen de quiénes son y sus roles, funciones y responsabilidades.
4. Entreviste a un auditor de TI y recopile la siguiente información:
a. ¿Cargo y empresa?
segundo. ¿Número de años de experiencia en auditoría de TI?
C. ¿Título (s) y certificaciones profesionales?
re. ¿Trayectoria profesional?
Página 55
mi. ¿Por qué se unió a la auditoría de TI?

F. ¿Le gusta y no le gusta la auditoría de TI?
gramo. ¿Dónde se ven a sí mismos dentro de 5 años?
5. Su gerente de auditoría de TI le solicita que:
a. Prepare una lista de al menos cinco certificaciones / designaciones profesionales que serían útiles
para el personal de auditoría de TI. En un formato de tabla de tres columnas, documente el nombre del
certificación o designación profesional, nombre de la organización profesional emisora,
razones por las que cree que sería relevante para el auditor de TI, y el enlace de origen del
Sitio web o fuente examinada.
Otras lecturas
1. Recursos NIIF de AICPA. ¿Qué son las NIIF? www.ifrs.com/ifrs_faqs.html#q1 (consultado en octubre de 2016).
2. Instituto Americano de Contadores Públicos Autorizados (AICPA). (2011). Principales iniciativas tecnológicas ,
www.aicpa.org/InterestAreas/InformationTechnology/Resources/TopTechnologyInitiatives/
Pages / 2011TopTechInitiatives.aspx
3. Chen, Y., Paxson, V. y Katz, RH (2010). ¿Qué hay de nuevo en la seguridad informática en la nube?
Informe técnico UCB / EECS-2010-5, Departamento de EECS, Universidad de California, Berkeley, 2010,
www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-5.html
4. Deloitte. Computación en la nube en 2016: problemas y oportunidades de empresas privadas, www2.deloitte.com/
us / en / pages / deloitte-growth-enterprise-services / articles / private-company-cloud-computing.html
(consultado en octubre de 2016).
5. Centro EY para Asuntos de la Junta. (Septiembre de 2015). EY Big Data y Analytics en el proceso de auditoría ,
www.ey.com/Publication/vwLUAssets/ey-big-data-and-analytics-in-the-audit-process/$FILE/ey-
big-data-and-analytics-in-the-audit-process.pdf (consultado en diciembre de 2015).
6. NIST. Versión final de la definición de computación en la nube del NIST publicada, www.nist.gov/news-events/
news / 2011/10 / final-version-nist-cloud-computing-definition-Published (consultado en octubre de 2011).
7. Gallegos, F. (2002). Debido cuidado profesional. Inf. Syst. Control J. , 2, 25-28.
8. Gallegos, F. (2003). Carreras de auditor de TI: el gobierno de TI proporciona nuevos roles y oportunidades. ES
Control J. , 3, 40–43.
9. Gallegos, F. y Carlin, A. (julio de 2007). Auditoría de TI: un proceso empresarial crítico. Computación. revista , 40 (7),
87–89.
10. Glosario de TI de Gartner. (Dakota del Norte). www.gartner.com/it-glossary/big-data/ (consultado en octubre de 2016).
11. ElOrganizations
ciclo exagerado de Gartner
Should para
Monitor, las tecnologías emergentes de 2015 identifica
www.gartner.com/newsroom/id/3114217 las innovaciones
(consultado informáticas que
en julio de 2015).
12. Gartner dice que Internet de las cosas transformará el centro de datos, www.gartner.com/newsroom/
id / 2684616 (consultado en octubre de 2014).
13. Asociación de Investigación de Delitos de Alta Tecnología. HTCIA.org
14. Ibrahim, N. Auditoría de TI 101: La auditoría interna es responsable de evaluar si los riesgos de TI son apropiados.
entendido, gestionado y controlado. Auditor interno , http://go.galegroup.com/ps/i.do?id=GA
LE% 7CA372553480 & sid = googleScholar & v = 2.1 & it = r & linkaccess = fulltext & issn = 00205745 & p = AO
NE & sw = w & authCount = 1 & u = melb26933 & selfRedirect = true (consultado en junio de 2014).
15. IDC. Se prevé que el gasto mundial en servicios de nube pública alcance los 266.000 millones de dólares en 2021, según
IDC. USA, www.idc.com/getdoc.jsp?containerId=prUS42889917 (consultado en julio de 2017).
16. Fundación de Auditoría y Control de Sistemas de Información. COBIT , quinta edición. Sistemas de información
Fundación de Auditoría y Control, Rolling Meadows, IL, www.isaca.org/Knowledge-Center/COBIT/
Pages / Overview.aspx (consultado en junio de 2012).
17. Asociación de Auditoría y Control de Sistemas de Información. (2011). Dominio del examen CISA , ISACA
Junta de certificación, Rolling Meadows, IL.
18. ISACA. Información sobre la innovación: principales tendencias digitales que afectan la estrategia. www.isaca.org/knowledge-C
Research / Pages / isaca-innovation-insights.aspx (consultado en marzo de 2015).
Página 56
19. ISACA. Perspectivas de innovación de ISACA, www.isaca.org/knowledge-center/research/pages/cloud.aspx

(consultado en septiembre de 2016).
20. ISACA. Perspectivas de innovación de ISACA, www.isaca.org/knowledge-Center/Research/Pages/isaca-innovation-
insights.aspx (consultado en septiembre de 2016).
21. ISACA. Glosario de ISACA, www.isaca.org/Pages/Glossary.aspx?tid=1095&char=A (consultado en octubre
2016).
22. ISACA. Glosario de ISACA, www.isaca.org/Pages/Glossary.aspx?tid=1490&char=I (consultado en octubre
2016).
23. ISACA. Glosario de ISACA, www.isaca.org/Pages/Glossary.aspx?tid=1489&char=I (consultado en octubre
2016).
24. ISACA. El código de ética profesional, el sitio web de la Asociación de Control de Auditoría de Sistemas de Información,
www.isaca.org
25. ISACA. Los programas de ISACA están alineados con el plan de estudios modelo para la auditoría y el control de SI, http: // ww
isaca.org/Knowledge-Center/Academia/Pages/Programs-Aligned-with-Model-Curriculum-for-IS-
Audit-and-Control.aspx (consultado en octubre de 2016).
26. Nelson, B., Phillips, A. y Steuart, C. (2010). Guía de Investigaciones y Ciencias Forenses en Computación , Curso
Tecnología, Cengage Learning, Boston, MA.
27. Otero, AR (2015). Impacto de la participación de los auditores de TI en las auditorías financieras. En t. J. Res. Autobús. Technol.
6 (3), 841–849.
28. Seguridad PCI. PCI Security Standards Council, www.pcisecuritystandards.org/pci_security/ (consultado
Octubre de 2016).
29. Plantillas de políticas de seguridad de la información de SANS. www.sans.org/security-resources/policies/general
30. Senft, S., Gallegos, F. y Davis, A. (2012). Control y Auditoría de Tecnologías de la Información . Prensa CRC /
Taylor y Francis, Boca Raton, FL.
31. Singleton, T. (2003). Las ramificaciones de Sarbanes-Oxley. IS Control J. , 3, 11–16.
32. AICPA. Declaraciones sobre estándares de auditoría, www.aicpa.org/research/standards/auditattest/pages/sas.
aspx # SAS117 (consultado en octubre de 2016).
33. Takabi, H., Joshi, JBD y Ahn, G. (2011). Desafíos de seguridad y privacidad en la computación en la nube
Ambientes. IEEE Secur. Priv. , 8 (6), 24–31.
34. Comisión Federal de Big Data de la Fundación TechAmerica. (2012). Desmitificando Big Data: una práctica
guía para transformar los negocios del gobierno, https://bigdatawg.nist.gov/_uploadfiles/M0068_
v1_3903747095.pdf (consultado en diciembre de 2012).
35. Las mejores soluciones de gestión de dispositivos móviles (MDM) de 2016. PC Magazine , www.pcmag.com/
article / 342695 / the-best-mobile-device-management-mdm-software-of-2016 (consultado en noviembre de 2016).
36. Iniciativa Nacional Integral de Ciberseguridad. www.whitehouse.gov/cybersecurity/comprehensive-
National-Cybersecurity-Initiative (consultado en julio de 2012).
37. Instituto de Auditores Internos. Definición de auditoría interna, www.iia.org.au/aboutIIA/definition-
OfIA.aspx (consultado en octubre de 2016).
38. Los 10 principales proveedores de software ERP y pronóstico del mercado 2015-2020. Las aplicaciones dirigen el mundo. www.
appsruntheworld.com/top-10-erp-software-vendors-and-market-forecast-2015-2020/ (consultado en octubre
2016).
39. Comisión de Bolsa y Valores de EE. UU. La SEC anuncia casos de fraude financiero . Presione soltar,
www.sec.gov/news/pressrelease/2016-74.html (consultado en octubre de 2016).
40. ¿Qué es la computación en la nube? PC Magazine , www.pcmag.com/article2/0,2817,2372163,00.asp (consultado
Noviembre de 2016).
41. Se prevé que el gasto mundial en servicios de nube pública se duplique para 2019, según IDC, https: //
www.informationweek.com/cloud/infrastructure-as-a-service/idc-public-cloud-spending-to-double-
by-2019 / d / d-id / 1324014 (consultado en octubre de 2016).
Página 57
Capitulo 2
Legislación relevante para

1. Analice los delitos informáticos y explique las tres categorías principales de delitos relacionados con las computadora
2. Defina el ciberataque e ilustre los recientes ciberataques realizados contra empresas estadounidenses.
3. Resumir la Ley Sarbanes-Oxley de la legislación federal sobre integridad financiera de 2002.
4. Describir y discutir la legislación federal de seguridad financiera relevante para los auditores de TI.
5. Describa y discuta la legislación relacionada con la privacidad relevante para los auditores de TI.
6. Analice las leyes estatales relevantes para los auditores de TI.
7. Discutir las leyes internacionales de privacidad relevantes para los auditores de TI.
Internet ha crecido exponencialmente a partir de un simple vínculo de relativamente pocos gobiernos y

computadoras educativas a una red mundial compleja que es utilizada por empresas, gobiernos,
y el público, casi todo el mundo, desde el especialista en informática hasta el usuario novato y todo el mundo en
Entre. Hoy en día, los usos comunes de Internet incluyen todo, desde contabilidad, marketing,
ventas y entretenimiento para correo electrónico, investigación, comercio y prácticamente cualquier otro tipo de
el intercambio de información. Al igual que con cualquier avance tecnológico, los avances también han dado lugar a
a la nueva legislación. Este capítulo se centra en la legislación que rige el uso y mal uso de la TI. Es
creía que la legislación ha tenido un impacto duradero en la comunidad en línea (gobierno, empresas,
y el público), que es algo que aquellos que ingresan a la auditoría de TI y aseguramiento de la información
profesión debe tener conocimiento.
Delitos informáticos y ciberataques

La explosión de la TI ha abierto muchas puertas de enlace nuevas para los delincuentes, lo que requiere que las organizacion
las precauciones necesarias para salvaguardar sus activos intelectuales contra los delitos informáticos. Conforme
al Informe de delitos en Internet de 2016, el Centro de quejas de delitos en Internet (IC3) del FBI recibió una
total de 298,728 quejas con pérdidas reportadas superiores a $ 1,3 mil millones. En 2015, el FBI recibió
31
Página 58
127.145 quejas de un total de 288.012 sobre presuntos delincuentes facilitados por Internet
actividad en realidad informó haber experimentado una pérdida. Las pérdidas totales reportadas en 2015 ascendieron a
$ 1,070,711,522 (o casi un 134% de aumento de la pérdida total reportada en 2014 de $ 800,492,073). En
2014, hubo 123,684 quejas recibidas (de un total de 269,422) por el FBI que en realidad
informó una pérdida de la actividad delictiva en línea. En 2015, la mayoría de las quejas continuas recibidas
por el FBI involucrados delincuentes que alojaban sitios web fraudulentos de servicios gubernamentales para adquirir
información de identificación personal (PII) y para cobrar tarifas fraudulentas de los consumidores. Otro
los más notables de 2014 a 2016 involucraron "falta de pago" (es decir, bienes / servicios enviados o
registrado, pero el pago nunca se realizó); "No entrega" (es decir, pago enviado, pero los bienes / servicios nunca
recibido); el robo de identidad; violación de datos personales; extorsión; y otros. Algunos de los más frecuentes
Los delitos de Internet denunciados de 2014 a 2016 se enumeran en el Anexo 2.1.
Hay tres categorías principales de delitos relacionados con las computadoras. Estos crímenes pueden cometerse
ted como actos individuales o al mismo tiempo. El primero de ellos es donde la computadora es el objetivo del
crimen. Generalmente, este tipo de delito implica el robo de información que se almacena en el
ordenador. Esto también cubre el acceso no autorizado o la modificación de registros. La forma más común de
obtener acceso no autorizado es para que el delincuente se convierta en un "superusuario" a través de una puerta trasera en e
sistema. La puerta trasera del sistema está ahí para permitir el acceso en caso de que surja un problema. Siendo un super-
usuario es equivalente a ser el administrador del sistema y permite al delincuente acceder a prácticamente todos los
áreas y funciones dentro del sistema. Este tipo de delito es el que más preocupa a la industria.
El siguiente tipo general de delito informático se produce cuando la computadora se utiliza como instrumento
del crimen. En este escenario, la computadora se utiliza para ayudar al criminal a cometer el
crimen. Esta categoría cubre el uso fraudulento de tarjetas de cajeros automáticos (ATM), tarjetas de crédito,
telecomunicaciones y fraude financiero por transacciones informáticas.
En la tercera categoría, la computadora no es necesaria para cometer el delito. La computadora es
incidental y se utiliza para cometer el delito más rápido, procesar mayores cantidades de información y
hacer que el crimen sea más difícil de identificar y rastrear. El ejemplo más popular de este crimen es
pornografía infantil. Debido al mayor acceso a Internet, la pornografía infantil está más extendida,
más fácil de acceder y más difícil de rastrear. Ayuda a las fuerzas del orden a perseguir este delito porque
La información incriminatoria a menudo se almacena en la computadora. Esto hace que la persecución penal
más fácil. Si el delincuente es inteligente, la computadora está programada para cifrar los datos o borrar los archivos
si no se accede correctamente. Por tanto, los campos de la informática forense y la seguridad informática son
abriendo nuevas oportunidades de trabajo para los profesionales de auditoría y seguridad que usan sus habilidades para captu
la evidencia.
Un delito informático notorio con el que suelen lidiar las organizaciones y que también puede
implican los tres tipos de delitos informáticos que acabamos de explicar, son ciberataques. El diccionario de Oxford
define el ciberataque como "un intento de piratas informáticos de dañar o destruir una red o sistema informático". *
Otra definición de ciberataque es la explotación deliberada y maliciosa de la red informática.
trabajos, sistemas y datos (generados por computadora) por individuos u organizaciones para obtener valiosos
información de los usuarios a través de medios fraudulentos. † Valioso, confidencial y / o sensible
La información puede tomar la forma de contraseñas, detalles financieros, información gubernamental clasificada,
etc. Los ciberataques se pueden etiquetar como campañas cibernéticas , guerra cibernética o terrorismo cibernético .
dependiendo de su contexto. El ciberterrorismo, por ejemplo, se analiza en una sección posterior dentro de este
capítulo.
* https://en.oxforddictionaries.com/definition/cyberattack.
† www.britannica.com/topic/cyberwar#ref1085374.
Página 59
Legislación relevante para la tecnología de la información ◾ 33
Figura 2.1 Crímenes de Internet reportados con frecuencia por los delitos de Internet del FBI
Centro de quejas (IC3) de 2014 a 2016
Crimen en Internet Descripción
email de negocios Estafa sofisticada dirigida a empresas que trabajan con empresas extranjeras
Compromiso (BEC) proveedores y / o empresas que realizan regularmente transferencias
pagos de transferencia.
Secuestro de datos El ransomware es una forma de malware dirigido tanto a humanos como a
debilidades técnicas en un esfuerzo por negar la disponibilidad de
datos y / o sistemas críticos.
Fraude de soporte técnico El fraude de soporte técnico ocurre cuando el sujeto afirma ser
asociado con un software informático o una empresa de seguridad, o
incluso una empresa de cable o de Internet, que ofrece soporte técnico
a la víctima.
Fraude automático La estafa típica de fraude automovilístico implica la venta de un

automóvil (incluido en un sitio web legítimo) con un precio
significativamente por debajo de su valor justo de mercado. El vendedor (estafador)
trata de apresurar la venta indicando que debe vender
inmediatamente debido a reubicación, problemas familiares, necesidad de efectivo o
otras razones personales. El vendedor no permite
inspeccionar el automóvil ni reunirse con el consumidor
cara a cara. Luego, el vendedor le pide al consumidor que transfiera
pago a un agente externo y enviar por fax el recibo de pago
de vuelta a él o ella como prueba de pago. El vendedor mantiene el
dinero y nunca llega a entregar el automóvil.
Gobierno Este tipo de delito en Internet implica hacerse pasar por gobierno, ley
Correo electrónico de suplantación funcionarios encargados de hacer cumplir la ley, o simplemente alguien que finge tener
Estafa cierto nivel de autoridad para persuadir a las víctimas inconscientes
para proporcionar su información personal.
Intimidación / Extorsión Este tipo de delito utiliza demandas de dinero, propiedad, activos,
Estafa etc. a través del ejercicio indebido de autoridad (es decir, amenazas de
daño físico, enjuiciamiento criminal o exposición pública) en
para extorsionar e intimidar.
Fraude inmobiliario Similar al fraude automático. El vendedor (estafador) intenta apresurar el

venta de una casa (con un precio significativamente por debajo de su mercado
tarifas de alquiler) indicando que debe vender inmediatamente debido
a reubicación, nuevo empleo, problemas familiares, necesidad de efectivo o
otras razones personales. Una reducción de precio tan significativa es
utilizado para atraer víctimas potenciales. El vendedor le preguntará al
consumidor para proporcionar información de identificación personal y para
pago electrónico a un tercero. Al recibir el pago, el
el vendedor nunca se encuentra.
Fraude de confianza / Este tipo de delito se refiere a esquemas diseñados para buscar
Estafa romántica compañerismo, amistad o romance a través de recursos en línea.
Página 60
Los ciberataques se han vuelto cada vez más comunes en los últimos años. Algunos de los más recientes y
Los infames ciberataques llevados a cabo contra empresas estadounidenses se enumeran en el Anexo 2.2. Discutamos ahora
legislación vigente (federal, estatal e internacional) para hacer frente a estos delitos informáticos
y ataques, y que son relevantes para el auditor de TI.
Figura 2.2 Ciberataques recientes contra empresas estadounidenses
Empresa / Industria Descripción del ciberataque
Verizon (2017) / Verizon, el principal proveedor de telecomunicaciones, sufrió una

Telecomunicaciones brecha de seguridad con más de 6 millones de clientes de EE. UU.
detalles expuestos en Internet. un
Yahoo # (2016) / Considerada por muchos como la mayor filtración de datos descubierta en el
Computadora de Internet historia de Internet. La infracción tuvo lugar a finales de 2014, cuando
Software los piratas informáticos robaron información asociada con al menos 500 millones
# Cuentas de usuario de Yahoo, incluidos nombres, direcciones de correo electrónico,
números de teléfono, seguridad encriptada o no encriptada
preguntas y respuestas, fechas de nacimiento y contraseña cifrada.
Yahoo # reveló públicamente la violación de datos 2 años después
22 de septiembre de 2016. b
Experian PLC (2015) / Servidores que almacenan información de evaluación crediticia (p. Ej., Nombres,
Servicios de negocios direcciones, números de seguridad social, etc.) de más de 15 millones
los clientes fueron atacados por piratas informáticos. C
WhatsApp Inc. (2015) / Hasta 200.000 usuarios estaban en riesgo de sufrir un ciberataque o tenían
Comunicaciones ya tenía información personal comprometida informó el
aplicación de mensajería multiplataforma. A través de Internet
conexión, WhatsApp proporciona servicios de mensajes de texto, reemplazando la
mensajes de texto SMS regulares. segundo
Himno, Inc. (2015) / Considerada la mayor brecha de salud hasta la fecha, el ciberataque
Atención médica administrada en Anthem afectado hasta 80 millones actuales y anteriores
clientes. Joseph Swedish, presidente y director ejecutivo de Anthem, Inc.
declaró que "Anthem fue el objetivo de un sofisticado
ciberataque externo ". d Los piratas informáticos obtuvieron acceso a los
sistema informático y obtuve información, incluidos nombres,
fechas de nacimiento, identificaciones médicas, números de seguro social,
direcciones, direcciones de correo electrónico e información de empleo,
incluidos los datos de ingresos.
Chick-Fil-A, Inc. (2014) / Ciberataques en sistemas de punto de venta durante 10 meses en

Restaurante numerosos restaurantes Chick-Fil-A dieron como resultado alrededor de 9.000 créditos
tarjetas comprometidas. segundo
Staples, Inc. (2014) / Malware (software que daña o desactiva los sistemas informáticos)
Al por menor se detectó en los sistemas de punto de venta de 115 tiendas, afectando
alrededor de 1,16 millones de tarjetas de crédito. segundo
( Continuacion )
Página 61
Figura 2.2 ( continuación ) Ciberataques recientes llevados a cabo contra empresas estadounidenses
Empresa / Industria Descripción del ciberataque
Sony Pictures Un ciberataque a la computadora de Sony Pictures Entertainment

Entertainment Inc. Las redes robaron cantidades significativas de información privada y confidencial.
(2014) / datos y también los dio a conocer al público. Los hackers eran
Entretenimiento se cree que está vinculado al gobierno de Corea del Norte, que
estaba extremadamente enojado con el principal estudio de cine de Hollywood por
producir una película (es decir, La entrevista) que retrata a North
Corea de manera negativa, y describió el asesinato de
su líder. mi
Corporación objetivo Ciberataque durante la temporada navideña de 2013

(2014) / Minorista comprometió los sistemas informáticos de Target y robó datos de
a 40 millones de tarjetas de crédito y débito de clientes. Considerado
la segunda infracción más grande informada por un minorista de EE. UU. F
a http://money.cnn.com/2017/07/12/technology/verizon-data-leaked-online/.
b www.cnbc.com/2016/09/22/yahoo-data-breach-is-among-the-biggest-in-history.html.
c www.heritage.org/research/reports/2015/11/cyber-attacks-on-us-companies-since-november-2014.
d www.usatoday.com/story/tech/2015/02/04/health-care-anthem-hacked/22900925/.
e www.vox.com/2014/12/14/7387945/sony-hack-explicado.
f www.reuters.com/article/us-target-breach-idUSBRE9BH1GX20131219.
Legislación federal de integridad financiera — Sarbanes – Oxley

Ley de 2002
Ha pasado más de una década desde el escándalo financiero de Enron-Arthur Andersen LLP (2001),
pero sigue afectando al mercado financiero actual, ya que la confianza del consumidor, el inversor,
y el gobierno para permitir a la industria autorregularse han sido violados. El recordatorio de
El fiasco de Enron son los escándalos de hoy en el mercado de inversiones hipotecarias y hipotecarias y el
efecto dominó que ha tenido en el gobierno, la industria privada y el público.
Por lo tanto, la Ley Sarbanes-Oxley (SOX) de 2002, que cambió el mundo de las finanzas
auditar de forma espectacular, será un vívido recordatorio de la importancia del debido cuidado profesional. SOX
prohíbe a todas las firmas contables públicas registradas proporcionar clientes de auditoría, contemporáneos
Además de la auditoría, ciertos servicios distintos de auditoría, incluida la subcontratación de auditoría interna,
servicios de diseño e implementación de sistemas de información y servicios de expertos, entre otros. Estas
Las restricciones del alcance del servicio van más allá de la existente Comisión de Seguridad e Intercambio (SEC) independ
regulaciones de la dependencia. Todos los demás servicios, incluidos los de impuestos, están permitidos solo si están aproba
por el comité de auditoría del emisor y todas las aprobaciones previas deben ser divulgadas en el informe periódico del emis
reporta a la SEC. Los emisores se refieren a una entidad legal (por ejemplo, corporaciones, etc.) que registra y vende
valores para financiar sus operaciones.
SOX analiza los requisitos para la Junta Directiva (junta), incluida la composición y
deberes. La junta debe (1) registrar firmas de contadores públicos; (2) establecer o adoptar, por regla, auditoría-
ing, control de calidad, ética, independencia y otras normas relacionadas con la preparación de la auditoría
informes para emisores; (3) realizar inspecciones de firmas contables; (4) realizar investigaciones y
Página 62
procedimientos disciplinarios e imponer las sanciones apropiadas; (5) realizar otros deberes o funciones
ciones según sea necesario o apropiado; (6) hacer cumplir la ley, las reglas de la junta, pro
las normas profesionales y las leyes de valores relacionadas con la preparación y emisión de informes de auditoría
y las obligaciones y responsabilidades de los contables al respecto; y (7) establecer el presupuesto y
administrar las operaciones de la junta y el personal de la junta.
SOX es un paquete de reforma importante que exige los cambios de mayor alcance. El Congreso tiene
impuesto al mundo empresarial desde la Ley de Prácticas Corruptas en el Extranjero de 1977 y la Ley de la SEC
de la década de 1930. Busca frustrar futuros escándalos y restaurar la confianza de los inversores, entre otros
cosas, (1) la creación de la Junta de Supervisión Contable de Empresas Públicas (PCAOB); (2) revisar
reglas de independencia del auditor y normas de gobierno corporativo; y (3) aumentar significativamente
las sanciones penales por infracciones de las leyes de valores. Estos se describen a continuación:
PCAOB
Para auditar una empresa que cotiza en bolsa, una empresa de contabilidad pública debe registrarse en la PCAOB. los
La PCAOB cobrará una tarifa de registro y una tarifa anual de cada contabilidad pública registrada.
Firme en cantidades suficientes para recuperar los costos de procesamiento y revisión de solicitudes.
e informes anuales. La PCAOB también establecerá una tarifa de apoyo contable anual razonable
para mantener sus operaciones.
Se deben realizar revisiones anuales de calidad para las firmas de contadores públicos que auditan más de
100 emisores; todos los demás deben realizarse cada 3 años. La SEC y la PCAOB pueden ordenar una
inspección especial de cualquier firma de auditoría registrada en cualquier momento. La PCAOB puede imponer sanciones
si la firma no supervisa razonablemente a alguna persona asociada con respecto a la auditoría o la calidad
normas de control.
Es ilegal que una firma de contabilidad pública registrada proporcione cualquier servicio que no sea de auditoría a un
emisor durante el mismo tiempo que la auditoría. Estos servicios que no son de auditoría se enumeran a continuación:
◾ Teneduría de libros u otros servicios relacionados con los registros contables o estados financieros de
el cliente de auditoría
◾ Diseño e implementación de SI financieros
◾ Servicios de tasación o valoración, opiniones de equidad o informes de contribución en especie
◾ Servicios actuariales
◾ Servicios de subcontratación de auditoría interna
◾ Funciones de gestión o recursos humanos
◾ Servicios de corredor o distribuidor, asesor de inversiones o banca de inversión
◾ Servicios legales y servicios de expertos no relacionados con la auditoría
La PCAOB puede, caso por caso, eximir de las prohibiciones enumeradas anteriormente a cualquier persona,
emisor, empresa de contabilidad pública o transacción, sujeta a revisión por parte de la comisión. sin embargo, el
La SEC tiene autoridad de supervisión y ejecución sobre la PCAOB. La PCAOB, en su reglamentación
proceso, debe tratarse como si fuera una asociación de valores registrada.
No será ilegal proporcionar otros servicios distintos a los de auditoría si el comité de auditoría aprueba previamente
ellos de la siguiente manera. SOX permite a una empresa de contabilidad participar en cualquier servicio que no sea de audit
incluidos los servicios fiscales que no se enumeran anteriormente, solo si el comité de auditoría del emisor
prueba la actividad. El comité de auditoría revelará a los inversores en informes periódicos su decisión.
para preaprobar servicios que no sean de auditoría. Las auditorías reglamentarias de las compañías de seguros legales se trat
servicio de auditoría y, por lo tanto, no requieren aprobación previa.
Página 63
Normas de independencia del auditor y normas de gobierno corporativo

Para la aceptación de la independencia, SOX requiere la rotación del auditor (no de la firma de auditoría). La auditoría princ
El socio coordinador y el socio de revisión deben rotar fuera de la auditoría cada 5 años. SOX
no establece ninguna distinción con respecto a la capacidad en la que el socio auditor líder o el
El socio de revisión proporcionó dichos servicios de auditoría. Cualquier servicio prestado como gerente o en algún otro
la capacidad parece contar para el período de 5 años. La provisión comienza tan pronto como se registra la empresa
Por lo tanto, en ausencia de una guía que indique lo contrario, el socio principal de auditoría y la revisión concurrente
El socio debe contar 5 años a partir de la fecha en que se produce el registro. También el
la firma contable debe informar al comité de auditoría todas las políticas y prácticas contables críticas
que se utilizarán, todos los métodos alternativos a los principios de contabilidad generalmente aceptados (PCGA) que
han sido discutidos con la gerencia, y las ramificaciones del uso de tales divulgaciones alternativas
y métodos.
Otro problema de cumplimiento de la independencia de auditoría es que el director ejecutivo (CEO),
troller, director financiero (CFO), director de contabilidad o persona en un puesto equivalente
no puede ser empleado por la firma de auditoría de la empresa durante el período de 1 año anterior a la auditoría. En
Además y para cumplir con la Sección 302: Responsabilidad corporativa por informes financieros,
por ejemplo, tanto el CEO como el CFO de la empresa deberán:
◾ preparar y firmar una declaración (que acompaña al informe de auditoría) para certificar a las partes interesadas
que los estados financieros de la empresa y todas las divulgaciones complementarias contenidas en
el informe es veraz, confiable y está bastante presente, en todos los aspectos materiales, las operaciones
y situación financiera de la empresa.
◾ declarar que efectivamente son responsables de implementar y mantener el control interno
estructura.
◾ respaldar que han implementado todos los pasos necesarios para garantizar que la divulgación
Los procesos y controles dentro de la empresa generan constantemente información financiera que puede
ser de confianza para las partes interesadas.
◾ presentar conclusiones sobre la eficacia de la estructura de control interno resultante de
su evaluación (dicha evaluación debe ocurrir dentro de los 90 días anteriores a la emisión del informe).
◾ identificar para los auditores externos de la empresa:
- cualquier deficiencia (significativa o no) en el diseño u operación de los controles internos que
podría afectar negativamente la capacidad de la empresa para registrar, procesar, resumir e informar
información financiera;
- cualquier debilidad material en los controles internos;
- cualquier fraude (material o no) que involucre a cualquier personal de la empresa que tenga una
papel en los controles internos de la empresa; y
- cualquier cambio significativo implementado que pueda afectar materialmente los controles internos
posterior a la fecha de su evaluación.
Una violación de esta sección debe ser consciente e intencional para dar lugar a responsabilidad. Será
Es ilegal que cualquier funcionario o director de un emisor tome cualquier acción para influir, coaccionar,
manipular o engañar a cualquier auditor involucrado en la realización de una auditoría con el propósito de
hacer que los estados financieros sean materialmente engañosos. Otra sección crítica y relacionada de
SOX es la Sección 404: Evaluación administrativa de controles internos, que requiere que el
Los auditores externos de pany informan sobre qué tan confiable es la evaluación de los controles internos realizados.
por la gerencia. Para ello, el paquete de informe financiero anual que elabora el
Página 64
Los auditores deben incluir un informe (es decir, un informe de control interno) que indique que la dirección es responsable.
para implementar y mantener una adecuada estructura de control interno. Dicho informe también debe
incluir la evaluación realizada por la gerencia para respaldar la efectividad de la estructura de control
ture. Cualquier falla, deficiencia o debilidad identificada como resultado de la evaluación también debe ser
informó. Los auditores externos deben dar fe de la exactitud de la gestión de la empresa.
afirmación de que existen controles contables internos que funcionan de manera eficaz.
Aumento de las sanciones penales por infracciones de las leyes de valores

SOX penaliza a los ejecutivos por incumplimiento. Si se requiere que un emisor prepare una reexpresión
debido al incumplimiento material de los requisitos de información financiera, el director ejecutivo y el director financiero
debe reembolsar al emisor cualquier bonificación u otra compensación basada en incentivos o acciones recibidas
durante los 12 meses siguientes a la emisión. SOX también prohíbe la compra o venta de acciones por
funcionarios y directores y otras personas con información privilegiada durante los períodos de bloqueo . Cualquier benefic
en violación de esto será recuperable por el emisor.
Cada informe financiero que deba prepararse de acuerdo con los PCGA reflejará todos los
ajustes de corrección de material que hayan sido identificados por una firma contable registrada. Cada
El informe financiero anual y trimestral revelará todas las transacciones importantes fuera del balance y
otras relaciones con entidades no consolidadas que pueden tener un efecto material presente o futuro
sobre la situación financiera del emisor. Además, los directores, funcionarios y el 10% o más propietarios deben
Informar las transacciones designadas al final del segundo día hábil siguiente al día en que
la transacción se ejecutó. SOX requiere que cada informe anual de un emisor contenga un
informe de control. La SEC emitirá reglas para exigir a los emisores que revelen si al menos un miembro
de su comité de auditoría es un experto financiero. Además, los emisores deben revelar información sobre material
cambios en la situación financiera o en las operaciones del emisor de forma rápida y actualizada.
SOX identifica como delito que cualquier persona altere, destruya, mutile u oculte corruptamente cualquier
documento con la intención de perjudicar la integridad o disponibilidad del objeto para su uso en un pro-
ceder u obstruir, influir o impedir de cualquier otra forma cualquier procedimiento oficial, siendo dicha persona
responsable de hasta 20 años de prisión y una multa.
La socio,
oficial, SEC también
personaestá autorizadaagente
controladora, a congelar el pago de
o empleado de una
un pago extraordinario
empresa durante unaa cualquier director,
investigación de
posibles infracciones de las leyes de valores. Finalmente, la SEC puede prohibir que una persona sirva como
funcionario o director de una empresa pública si la persona ha cometido fraude de valores.
Legislación de seguridad federal

Parece que los métodos y técnicas de seguridad tradicionales simplemente no funcionan. De hecho, la literatura
erature sostiene que el uso actual de herramientas y tecnologías de seguridad de la información (por ejemplo, cifrado,
cortafuegos, gestión de acceso, etc.) por sí sola no es suficiente para proteger la información y la dirección
desafíos de seguridad de la información. Del mismo modo, la legislación de seguridad actual, aunque aborda cuestiones de
entrada no deseada en una red, puede permitir formas en las que los delincuentes puedan escapar de las situaciones más grav
sanciones por violar el acceso autorizado a un sistema informático. La industria de las redes informáticas
está cambiando continuamente. Debido a esto, las leyes, políticas, procedimientos y pautas deben
cambiar con él; de lo contrario, tenderán a volverse obsoletos, ineficaces y obsoletos.
En el pasado, la industria privada se ha mostrado reacia a implementar estos
leyes de desarrollo debido al temor al impacto negativo que podría traer a la
Página 65
Legislación pertinente a las tecnologías de la información ◾ 39
ganancias futuras e imagen para el público. A continuación se presentan descripciones de algunos de los
Leyes gubernamentales que regulan la seguridad informática.
Ley de fraude y abuso informáticos de 1984

La Ley de Abuso y Fraude Informático (CFAA) se redactó por primera vez en 1984 como respuesta a la
crimen. La respuesta del gobierno a la seguridad de la red y los delitos relacionados con la red fue revisar
la ley en 1994 bajo la Ley de Enmiendas de Abuso Informático para cubrir delitos como la entrada ilegal
(entrada no autorizada) en un sistema en línea, excediendo el acceso autorizado e intercambiando información
información sobre cómo obtener acceso no autorizado. Aunque la ley estaba destinada a proteger contra
ataques en un entorno de red, también tiene su parte justa de fallas.
La ley requiere que se cumplan ciertas condiciones para que el delito sea una violación de
la CFAA. Solo si se dan estas condiciones, el delito se considerará una violación de la CFAA. los
tres tipos de ataques que están cubiertos por la Ley y las condiciones que deben cumplirse incluyen:
◾ Allanamiento fraudulento. Esto es cuando se comete una infracción con la intención de defraudar que resulta en
tanto promoviendo el fraude como el atacante obteniendo algo de valor.
◾ Traspaso destructivo intencional. Esta es una infracción junto con acciones que intencionalmente causan
daños a una computadora, sistema informático, red, información, datos o programa, o resultados
en denegación de servicio y causa al menos $ 1,000 en pérdida total en el transcurso de un año.
◾ Invasión destructiva imprudente. Aquí es cuando hay presencia de transgresión junto con imprudencia
acciones (aunque no deliberadamente dañinas) que causan daños a una computadora, computadora
sistema, red, información, datos o programa, o resulta en la denegación del servicio y causas en
menos $ 1,000 en pérdida total en el transcurso de un año.
Cada una de las definiciones anteriores está orientada a un tipo particular de ataque. La invasión fraudulenta fue
una respuesta contra los delitos de fraude telefónico que se comete a través de un sistema informático
tem, como utilizar la computadora de una compañía telefónica para obtener servicio telefónico gratuito. Esta condición
ayuda a procesar a las personas responsables de las grandes pérdidas económicas sufridas por empresas como
como AT&T.
compañías El fraude Los
telefónicas. de llamadas
otros dostelefónicas se haseconvertido
generalmente en sistemas
aplican a los un problema de más
en línea y sedehan
milimplementado
millones de dólares
para al año pa
abordar problemas de piratas informáticos o crackers, gusanos, virus y prácticamente cualquier otro tipo de intruso
que pueden dañar, alterar o destruir información. Estos dos ataques son similares en muchos aspectos, pero
La clave para diferenciar los dos son las palabras "intencional", que, por supuesto, significaría un
ataque deliberado con la intención de causar daño, mientras que "imprudente" puede cubrir un ataque en el que
El daño fue causado por negligencia. Las sanciones bajo la Sección 1030 (c) de la CFAA varían de
1 año de prisión por allanamiento destructivo imprudente en una computadora no federal hasta 20 años
por un ataque intencional a una computadora federal donde la información obtenida se utiliza para "la
daño de los Estados Unidos o en beneficio de cualquier nación extranjera ”(es decir, casos de espionaje).
Ley de seguridad informática de 1987

Otro acto de importancia es la Ley de Seguridad Informática de 1987, que fue redactada con motivo de un congreso.
preocupaciones nacionales y conciencia pública sobre cuestiones relacionadas con la seguridad informática y debido a contr
sobre el control de la información no clasificada. El propósito general de la ley era una declaración de
el gobierno que mejora la seguridad de la información confidencial en los sistemas informáticos federales
es de interés público. La Ley estableció un programa de seguridad informática del gobierno federal que
Página 66
protegería la información confidencial en los sistemas informáticos del gobierno federal. También se desarrollaría
normas y directrices para los sistemas informáticos federales no clasificados y facilitan dicha protección. *
La Ley de seguridad informática de 1987 también asignó la responsabilidad de desarrollar el gobierno
amplios estándares de seguridad de sistemas informáticos, pautas y programas de capacitación en seguridad para el
Oficina Nacional de Estándares (ahora NIST). Además, estableció un sistema informático de seguridad
y la Junta Asesora de Privacidad dentro del Departamento de Comercio, y agencias federales requeridas
para identificar los sistemas informáticos que contienen información sensible y desarrollar planes de seguridad para aquellos
sistemas. Finalmente, brindó capacitación periódica en seguridad informática a todos los empleados federales y
contratistas que administraron, utilizaron u operaron sistemas informáticos federales.
La Ley de seguridad informática de 1987 es particularmente importante porque es fundamental para la
desarrollo de estándares federales para salvaguardar la información no clasificada y establecer un equilibrio
ance entre la seguridad nacional y otros asuntos no clasificados en la implementación de políticas de seguridad
dentro del gobierno federal. También es importante para abordar cuestiones relativas al gobierno.
control de la criptografía .
Ley de seguridad nacional de 2002

Los eventos del ataque terrorista del 11 de septiembre de 2001 provocaron la aprobación del Departamento de Seguridad Na
Ley de 2002, cuyo propósito era prevenir ataques terroristas dentro de los Estados Unidos y reducir
la vulnerabilidad de los Estados Unidos al terrorismo. Desempeña un papel importante en la seguridad de los
espacio porque impone muchas limitaciones y restricciones a los usuarios de Internet. Por ejemplo,
Uno de los objetivos de la ley es establecer un sistema basado en Internet que solo permitirá a las personas autorizadas
el acceso a determinada información o servicios. Debido a esta restricción, las posibilidades de vulnerabilidad
la capacidad y los ataques pueden disminuir. El impacto de esta ley contribuirá definitivamente a la seguridad
del ciberespacio porque su función principal es proteger a la gente de los Estados Unidos de cualquier
forma de ataque, incluidos los ataques de Internet. La aprobación de la Ley de Seguridad Nacional de 2002 y
la inclusión de la Ley de Mejora de la Seguridad Cibernética (CSEA) dentro de esa Ley hace que sea necesario
Sea consciente y practique la ciberseguridad como asunto de todos.
La CSEA (HR 3482) se incorporó a la Ley de Seguridad Nacional de 2002. La CSEA
exige cadenas perpetuas para los piratas informáticos que ponen en peligro vidas imprudentemente. La ley también incluía
disposiciones que buscan permitir que la vigilancia de la red recopile números de teléfono, Protocolo de Internet
Direcciones (IP) y localizadores de recursos universales (URL) o información de correo electrónico sin recurrir a
un tribunal donde se sospecha una “amenaza inmediata a un interés de seguridad nacional”. Finalmente, Internet
Los proveedores de servicios (ISP) deben entregar los registros de los usuarios a las autoridades policiales.
derogar la legislación vigente que prohíbe tal comportamiento.
La Ley de Seguridad Nacional de 2002 agregó una redacción que busca prohibir la publicación en cualquier caso.
donde de detalles de herramientas como Pretty Good Privacy, que codifican correos electrónicos para que no puedan ser
leído por fisgones. Esta disposición permite a la policía realizar escuchas telefónicas o por Internet.
domly sin necesidad de pedir permiso a un tribunal primero. Esta ley tiene una disposición que exige
castigo de hasta cadena perpetua para los piratas informáticos electrónicos que sean declarados culpables de causar la muerte
otros a través de sus acciones. Cualquier pirata informático condenado por causar lesiones a otras personas podría enfrentars
términos de hasta 20 años según las disposiciones sobre delitos cibernéticos, que se encuentran en la Sección 225 de la dispo
de la Ley de Seguridad Nacional.
* Office of Technology Assessment, Issue Update on Information Security and Privacy in Networked
Ambientes, pág. 105.
Página 67
Normas de seguridad de datos de la industria de tarjetas de pago de 2004

Los estándares de seguridad de datos de la industria de tarjetas de pago (PCI DSS) se refieren a
requisitos aplicables a las entidades que almacenan, procesan o transmiten datos de titulares de tarjetas, con el
intención de proteger dichos datos para reducir el fraude con tarjetas de crédito. Se mantienen las PCI DSS,
gestionado y promovido por el PCI Security Standards Council (Council) en todo el mundo para proteger
datos del titular de la tarjeta. El Consejo fue fundado en 2006 por las principales empresas de tarjetas de crédito, como
American Express, Discover, JCB International, MasterCard y Visa, Inc. Estas empresas
compartir por igual en la gobernanza, ejecución y cumplimiento del trabajo del Consejo.
Todos los comerciantes que aceptan o procesan pagos mediante tarjetas deben cumplir con la PCI
DSS. Algunos objetivos y requisitos específicos de PCI DSS incluyen los siguientes:
◾ Crear y mantener una red segura: implementar una configuración de firewall sólida;
Evite el uso de valores predeterminados proporcionados por el proveedor para las contraseñas del sistema que son fác
◾ Protección de los datos almacenados del titular de la tarjeta: utilice técnicas de cifrado en todas las transmisiones de
datos del titular de la tarjeta
◾ Mantener un programa de gestión de vulnerabilidades: desarrollar sistemas más fuertes y seguros;
implementar (y actualizar según sea necesario) software o programas antivirus
◾ Implementar fuertes medidas de control de acceso: asigne identificaciones únicas; configurar el acceso a la tarjeta
los datos del titular al nivel mínimo posible de acuerdo con las necesidades comerciales, tareas relacionadas y
responsabilidades (es decir, principio de privilegio mínimo); restringir el acceso físico a los datos del titular de la tarje
◾ Monitorear y probar redes: monitorear todo el acceso a los recursos de red donde la tarjeta
se están transmitiendo datos del titular; probar regularmente los sistemas de seguridad que transmiten y
cesar los datos del titular de la tarjeta
◾ Mantener una política de seguridad de la información: especificar las características de seguridad requeridas y aceptar
pautas de uso capaz para los usuarios; definir las expectativas, responsabilidades y derechos de acceso del usuario y
privilegios
Ley federal de administración de seguridad de la información de 2002

La Ley Federal de Gestión de Seguridad de la Información (FISMA) fue promulgada como parte de la
Ley de gobierno electrónico de 2002 para "proporcionar un marco integral para garantizar la eficacia
de los controles de seguridad de la información sobre los recursos de información que respaldan las operaciones federales y
activos y para proporcionar el desarrollo y mantenimiento de los controles mínimos necesarios para proteger
Sistemas de información e información federal ”. En otras palabras, FISMA requiere que las agencias federales
desarrollar, documentar y poner en marcha programas de seguridad de la información con el propósito de
proteger tanto la información como los sistemas implementados para apoyar las operaciones y activos de
las agencias, incluidas las proporcionadas o administradas por otra agencia, contratista u otra fuente.
Específicamente, FISMA requiere que las agencias federales:
◾ asegurarse de que se asigne seguridad a los funcionarios apropiados (por ejemplo, el director de información, etc.)
responsabilidad y autoridad para asegurar el cumplimiento de los requisitos impuestos por FISMA
◾ planificar e implementar programas de seguridad de la información
◾ desarrollar y mantener inventarios de los principales sistemas de información de la agencia
◾ tener evaluaciones independientes anuales (es decir, libres de cualquier sesgo o influencia) de su información
programa y prácticas de seguridad
◾ informar sobre la idoneidad y eficacia de sus controles, políticas,
procedimientos y prácticas
Página 68
Es fundamental que las agencias comprendan y, lo más importante, implementen las tareas enumeradas anteriormente.
con el fin de mitigar los riesgos a niveles aceptables y otros factores que podrían afectar adversamente su
Misiones Las agencias deben monitorear y evaluar constantemente sus programas de seguridad de la información para
salvaguardar la información (y los sistemas que la generan) de eventos que puedan resultar de una
acceso personalizado, así como el uso, divulgación, interrupción, modificación o destrucción de la información.
Leyes de firma electrónica: transacciones electrónicas uniformes

Ley de 1999 y firmas electrónicas en todo el mundo
y la Ley de Comercio Nacional de 2000
Un área de preocupación para muchas empresas son las firmas electrónicas. Similar al almacenamiento en línea,
Las firmas electrónicas pueden mejorar significativamente las operaciones comerciales, aunque “se debe tener cuidado
tomado para evitar comprometer los datos confidenciales del cliente y / o violar las regulaciones gubernamentales sobre
el tema."
Existen al menos dos leyes principales con respecto a las leyes de firma electrónica que
las empresas deben conocer: Ley Uniforme de Transacciones Electrónicas (UETA) y
Firmas en la Ley de Comercio Nacional y Global (ESIGN). Con estas dos leyes, las empresas pueden
acelerar significativamente los tiempos de respuesta de las transacciones comerciales al declarar su acuerdo con el contrato
tuales con solo un clic del mouse (es decir, reemplazando los documentos tradicionales de firma en papel con
formularios electrónicos).
UETA es una de las varias leyes uniformes de EE. UU. Propuestas por la Conferencia Nacional de
Comisionados de Leyes Estatales Uniformes. Existe para armonizar las leyes estatales relativas a la retención de
registros en papel (especialmente cheques) y validez de firmas electrónicas. UETA se introdujo en
1999 y ha sido adoptado por 47 estados de EE. UU., Así como el Distrito de Columbia, Puerto Rico y
las Islas Vírgenes de los Estados Unidos. En pocas palabras, UETA hace que las firmas electrónicas sean válidas y cumplan
los requisitos de la ley cuando las partes listas para realizar una transacción han acordado proceder electrónicamente.
ESIGN, por otro lado, es una ley federal aprobada por el Congreso de los Estados Unidos en 2000. Como UETA,
ESIGN reconoce las firmas electrónicas y los registros otorgados a todas las partes contratantes que optan por utilizar elec-
tronic y firmarlos electrónicamente. En otras palabras, con ESIGN, documentos con
Las firmas y registros electrónicos son tan buenos como sus equivalentes en papel estándar, y
por lo tanto, sujeto al mismo examen legal de autenticidad que se aplica al papel tradicional
documentos y firmas de tinta húmeda.
Para que una firma electrónica sea reconocida como válida bajo la ley de EE. UU. (ESIGN y UETA), el
debe tener lugar lo siguiente:
◾ Debe haber una clara intención de firmar por todas las partes involucradas.
◾ Las partes de la transacción deben dar su consentimiento para hacer negocios electrónicamente.
◾ El sistema de aplicación utilizado para la captura de la firma electrónica debe estar configurado y
listo para retener (con fines de validación) todos los pasos de procesamiento realizados para generar el
firma electrónica, así como los registros de firma electrónica necesarios para una precisión y
reproducción o restauración oportuna, si es necesario.
Legislación de privacidad
Sobre el tema de la privacidad, en 2009, el Departamento de Salud Pública de California (CDPH) encontró
que un Hospital de Niños del Condado de Orange envió los registros de los pacientes por error a un taller de automóviles.
Página 69
El negocio de talleres automotrices recibió seis faxes que contenían información médica, incluida información
información que identificó el nombre del paciente, la fecha de nacimiento y los detalles de las visitas. El personal del hospita
el CDPH que se debería haber enviado un fax de prueba primero, según la política del hospital. Éste es un ejemplo de un
violación de la privacidad. La privacidad, según la definición de ISACA, implica la "libertad de intrusión no autorizada
o divulgación de información sobre un individuo ". La privacidad se centra en proteger la información personal
información sobre clientes, empleados, proveedores o socios comerciales. Las organizaciones tienen una ética
y obligación moral de implementar controles para proteger la información personal que recopilan.
Los delincuentes también han accedido a la privacidad de la información en el mundo en línea. Algunos de
la legislación aprobada protege al usuario contra la invasión de la privacidad. Sin embargo, algunas de las leyes
observados contienen demasiadas excepciones y exclusiones hasta el punto de que su eficacia se resiente. En
Además, el gobierno continúa utilizando técnicas de vanguardia con el propósito de acceder
obtener información por el bien de la "seguridad nacional" justificada actualmente bajo la Seguridad Nacional
Actuar. Los nuevos proyectos de ley y la legislación continúan intentando encontrar una solución a estos problemas, pero nu
Es necesario establecer directrices, políticas y procedimientos, y es necesario hacer cumplir las leyes para sus
en toda su extensión para que los ciudadanos disfruten de su derecho a la privacidad garantizado por la constitución.
Ley de privacidad de 1974

Además del derecho básico a la privacidad al que tiene derecho una persona según la Constitución de los Estados Unidos,
el gobierno también promulgó la Ley de Privacidad de 1974. El propósito de esto es proporcionar ciertos
salvaguardas a un individuo contra una invasión de la privacidad personal. Esta ley impone ciertos requisitos
sobre agencias federales, como permitir que las personas * :
◾ determinar qué registros personales recopilan y mantienen las agencias federales

◾ evitar que los registros personales que se obtuvieron para un propósito particular se utilicen o
puesto a disposición para otro propósito sin consentimiento
◾ obtener acceso a su información personal en los registros de la agencia federal y corregir o enmendar
ellos
La ley también requiere que las agencias federales recopilen, mantengan y utilicen cualquier información privada en un
manera que asegure que dicha acción tiene un propósito necesario y legal, que la información
es actual y precisa, y que se proporcionan salvaguardas para evitar el uso indebido de la información.
Aunque la Ley de Privacidad de 1974 es una parte importante para salvaguardar la privacidad individual
derechos, es importante que el auditor de TI reconozca que existen muchas exenciones bajo las cuales
puede ser legal que se divulgue cierta información. Esto podría, en algunos casos, permitir
y agencias no federales los medios por los cuales pueden obtener y divulgar información sobre cualquier
individuos simplemente porque pueden caer bajo una de las muchas exenciones que la Ley de Privacidad
permite. Por ejemplo, la subsecuente Ley de Libertad de Información proporciona al gobierno federal
una forma de divulgar información histórica al público de forma controlada. La Ley de Privacidad de
1974 también se ha actualizado con el tiempo mediante el proceso de enmienda.
Ley de Privacidad de Comunicaciones Electrónicas de 1986

En el área de redes de computadoras, la Ley de Privacidad de Comunicaciones Electrónicas de 1986 es una
de las primeras piezas legislativas principales contra la violación de la información privada según sea aplicable a
* Archivo de información / privacidad de RSE, Ley de privacidad de 1974 y enmiendas.
Página 70
sistemas en línea. La Ley prohíbe específicamente la interceptación y divulgación de comunicaciones electrónicas, orales o e
comunicaciones tronic, así como la fabricación o posesión de dispositivos interceptores.
Ley de Decencia en las Comunicaciones de 1996

La Ley de Decencia de la Comunicación (CDA) de 1996 prohíbe la realización de "indecentes" o "claramente
material ofensivo ”disponible para los menores a través de redes informáticas. La ley impone una multa de hasta
hasta 250.000 dólares y pena de prisión de hasta 2 años. La CDA exime específicamente de responsabilidad
cualquier persona que proporcione acceso o conexión o forme una instalación, sistema o red que no sea
bajo el control de la persona que viola la ley. La CDA también establece que un empleador no debe
ser responsable de las acciones de un empleado a menos que la conducta del empleado esté dentro del alcance de
su empleo. La aplicación más reciente de esta ley se ha utilizado para proteger el uso de menores de
redes sociales y ser presa de depredadores / acosadores.
Ley de protección de la privacidad infantil en línea de 1998

Esta es otra ley aprobada por el Congreso después de la CDA, vigente en abril de 2000. The Children's
La Ley de Protección de la Privacidad en Línea (COPPA) de 1998 se aplica a la recopilación en línea de información person
información de niños menores de 13 años. Las nuevas reglas detallan lo que un operador de sitio web debe incluir en un
política de privacidad cuándo y cómo buscar el consentimiento verificable de un padre, y qué responsabilidades
El operador tiene que proteger la privacidad y seguridad de los niños en línea. Operadores o propietarios de un comercial
El sitio web o un servicio en línea dirigido a niños menores de 13 años debe cumplir con la COPPA
al recopilar información personal de dichos niños.
Para determinar si un sitio web está dirigido a niños, la Comisión Federal de Comercio (FTC)
considera varios factores, incluido el tema; contenido visual o de audio; la edad de los modelos
en el sitio; idioma; si la publicidad en el sitio web está dirigida a niños; información
con respecto a la edad de la audiencia real o prevista; y si un sitio usa personajes animados
u otras características orientadas a los niños.
Para determinar si una entidad es un "operador" con respecto a la información recopilada en un
sitio, la FTC considerará quién posee y controla la información, quién paga por la recopilación
y mantenimiento de la información, cuáles son las relaciones contractuales preexistentes en
relación con la información, y qué papel juega el sitio web en la recopilación o el mantenimiento de la
información.
En 2008, el Congreso enmendó esta Ley y la incluyó como Título II “Protección de los niños” de
la Ley de mejora de datos de banda ancha de 2008, Ley Pública 110-385, 10 de octubre de 2008. La
La enmienda define específicamente la información personal de un niño. La información personal está definida
como información de identificación individual sobre un niño que se recopila en línea, como el nombre completo,
domicilio, dirección de correo electrónico, número de teléfono o cualquier otra información que permita
alguien para identificar o contactar al niño. La ley también cubre otros tipos de información, para
ejemplo, pasatiempos, intereses e información recopilada a través de cookies u otros tipos de seguimiento
mecanismos, cuando están vinculados a información identificable individualmente.
Ley de Portabilidad y Responsabilidad del Seguro Médico de 1996

Los estándares nacionales para transacciones electrónicas fomentan el comercio electrónico en el sector sanitario.
industria y, en última instancia, simplificar los procesos involucrados. Esto resulta en ahorros de la reducción
en cargas administrativas sobre los proveedores de atención médica y los planes de salud. Hoy, los proveedores de atención m
Página 71
y los planes de salud que realizan negocios electrónicamente deben usar muchos formatos diferentes para
actas. Por ejemplo, en la actualidad existen alrededor de 400 formatos diferentes para reclamos de atención médica. Con un
estándar nacional para reclamos electrónicos y otras transacciones, los proveedores de atención médica pueden sub-
mit la misma transacción a cualquier plan de salud en los Estados Unidos y el plan de salud debe aceptarla.
Los planes de salud también pueden enviar transacciones electrónicas estándar, como avisos de remesas y
autorizaciones de derivación a proveedores de atención médica. Estos estándares nacionales hacen que los datos electrónicos
cambiar una alternativa viable y preferible al procesamiento de papel tanto para proveedores como para planes de salud.
Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) de 1996, la primera
normas de privacidad para proteger los registros médicos de los pacientes y otra información de salud proporcionada a
Los planes de salud, médicos, hospitales y otros proveedores de atención médica entraron en vigencia el 14 de abril de 2003
Desarrollados por el Departamento de Salud y Servicios Humanos, estos nuevos estándares brindan
pacientes con acceso a sus registros médicos y más control sobre cómo su salud personal
se utiliza y divulga la información. Representan un piso federal uniforme de protección de la privacidad.
para los consumidores de todo el país. Las leyes estatales que brindan protecciones adicionales a los consumidores no son
afectados por esta nueva regla.
HIPAA pide una estricta protección de seguridad en la información de salud electrónica mientras se
mantenido y transmitido. Para los directores de TI, cumplir con los requisitos de privacidad de HIPAA es
principalmente una cuestión de seguridad informática que protege la confidencialidad de la información médica del paciente
mación y estandarización de los procesos de notificación y facturación para todos los relacionados con la salud y
información. La confidencialidad se refiere a la protección de cualquier tipo de información sensible de
Acceso no autorizado. Es fundamental para la reputación de una organización y también para cumplir con la privacidad
regulaciones. Los riesgos asociados con la confidencialidad incluyen permitir el acceso o la divulgación no autorizados
seguro de los datos sensibles y valiosos de la organización (por ejemplo, planes estratégicos corporativos, información del as
mación, etc.). Desde el punto de vista de una organización, la información sensible y / o crítica puede incluir:
◾ Planes estratégicos
◾ Secretos comerciales
◾ Información de costos
◾ Documentos legales
◾ Mejoras de proceso
Para cumplir con HIPAA, debe ocurrir lo siguiente:
◾ Cualquier conexión a Internet u otras redes o sistemas externos se produce a través de

puerta de enlace o firewall .
◾ La autenticación fuerte se utiliza para restringir el acceso a sistemas críticos o procesos comerciales.
y datos altamente sensibles.
◾ Las evaluaciones de vulnerabilidad, confiabilidad y el entorno de amenazas se realizan al menos
anualmente.
La tecnología de la información sanitaria para fines económicos y

Salud clínica de 2009
Ley de tecnología de la información sanitaria para la salud económica y clínica (HITECH) de 2009
fue promulgada como parte de la Ley de Recuperación y Reinversión Estadounidense de 2009. HITECH promueve
la adopción y el uso significativo de las tecnologías de la información para la salud en los Estados Unidos. HITECH proporc
Departamento de Salud y Servicios Humanos con autoridad para establecer programas para mejorar
Página 72
calidad, seguridad y eficiencia de la atención médica a través del "uso significativo" y la promoción de la TI para la salud,
incluyendo registros de salud electrónicos e intercambio electrónico de información de salud privado y seguro.
El uso significativo se refiere a los estándares mínimos del gobierno de EE. UU. Para el uso de registros médicos electrónico
y para intercambiar datos clínicos de pacientes entre proveedores de atención médica, proveedores de atención médica y
aseguradoras, proveedores de atención médica y pacientes. Las secciones dentro de HITECH incluyen las siguientes:
◾ Subtítulo A: Promoción de la TI para la salud

◾ Subtítulo B: Pruebas de TI para la salud
◾ Subtítulo C — Financiamiento de subvenciones y préstamos
◾ Subtítulo D: Privacidad
Los objetivos del Subtítulo A incluyen la protección y salvaguarda de la información médica de cada paciente.
consistente con la ley; mejora de la calidad de la asistencia sanitaria; y reducción de errores médicos
y los costes sanitarios resultantes de la ineficiencia; entre otros. El subtítulo B enumera descripciones y
requisitos para: (1) probar e implementar estándares de Tecnología de la Información de Salud (HIT);
(2) pruebas de la infraestructura HIT (por ejemplo, bancos de pruebas técnicas, etc.); y (3) ayudar a la educación superior
instituciones para establecer Centros multidisciplinarios para la empresa de información sanitaria
Integración. El subtítulo C implementa subvenciones, préstamos y programas de demostración como incentivos para
utilizando TI de salud. Por último, el subtítulo D se ocupa de las preocupaciones de privacidad y seguridad relacionadas con
transmisiones de información sanitaria.
Tanto HITECH como HIPAA, aunque son leyes independientes y no relacionadas, se complementan en
algunas maneras. Por ejemplo, HITECH exige que sus tecnologías y estándares relacionados con TI no
comprometer las leyes de privacidad y seguridad de HIPAA. HITECH también estipula que los médicos y hospitales
pitales que certifiquen un uso significativo, deben haber realizado previamente una evaluación de riesgos de seguridad, com
Requiere HIPAA. HITECH además establece reglas de notificación para instancias de violación de datos, que
también se reflejan en HIPAA.
Ley Gramm-Leach-Bliley de 1999

La Ley Gramm-Leach-Bliley de 1999 requiere que las instituciones financieras protejan las finanzas del consumidor.
privacidad cial. Las instituciones financieras son empresas que ofrecen a los consumidores productos o servicios financieros
vicios como préstamos, asesoramiento financiero o de inversión o seguros. Bajo la Ley Gramm-Leach-Bliley
de 1999, las instituciones financieras deben explicar sus prácticas de intercambio de información a sus
clientes y proteger sus datos sensibles.
Para cumplir con la Ley, las instituciones financieras deben evaluar, administrar y controlar el riesgo;
supervisar a los proveedores de servicios; y ajustar los programas de seguridad según sea necesario en función de los riesgos
disposición específica requiere que las instituciones financieras identifiquen las amenazas internas y / o externas que
potencialmente puede resultar en divulgaciones no autorizadas, así como en mal uso, destrucción o manipulación
de la información confidencial del cliente.
Uniendo y fortaleciendo a Estados Unidos proporcionando

Herramientas necesarias para interceptar y obstruir el terrorismo
Ley (Ley Patriota de EE. UU.) De 2001
El propósito de la Ley USA PATRIOT de 2001 es disuadir y castigar los actos terroristas en el
Estados Unidos y en todo el mundo, para mejorar las herramientas de investigación de las fuerzas del orden y otras
propósitos, algunos de los cuales incluyen:
Página 73
◾ Fortalecer las medidas estadounidenses para prevenir, detectar y enjuiciar el lavado de dinero internacional
Derivación y financiación del terrorismo.
◾ Sujeto a escrutinio especial jurisdicciones extranjeras, instituciones financieras extranjeras y clases
de transacciones internacionales o tipos de cuentas susceptibles de abuso criminal
◾ Requerir que todos los elementos apropiados de la industria de servicios financieros informen
lavado de dinero
◾ Fortalecer las medidas para prevenir el uso del sistema financiero estadounidense para beneficio personal por parte de
romper funcionarios extranjeros y facilitar la repatriación de activos robados a los ciudadanos de países para
a quién pertenecen tales activos
Lamentablemente, el terrorismo sigue ocurriendo y no hay muchas señales de que vaya a desaparecer pronto. por
ejemplo, el Congreso debe monitorear continuamente la empresa antiterrorista estadounidense y
mía si se necesitan otras medidas para mejorarlo. Como se menciona en un artículo de 2015
de The Heritage Foundation, y relevante para los temas discutidos en este libro de texto, cyber-
Las capacidades de investigación deben ser priorizadas por el Congreso. Con tanto terrorismo relacionado
actividad que ocurre en Internet, la aplicación de la ley debe ser capaz de identificar, monitorear,
y rastrear esa actividad violenta de manera efectiva y oportuna. Ciberataques severos, como
como ciberterrorismo, son capaces de apagar centrifugadoras nucleares, sistemas de defensa aérea y
Redes eléctricas. Para algunos, este tipo de ataques deben tratarse como actos de guerra, ya que plantean
una seria amenaza para la seguridad nacional. Algunos de los recientes e importantes ciberterrorismos en el
Estados Unidos incluye:
◾ Ciberataques y ciberespionaje llevados a cabo por China contra los EE. UU. Y su explotación
redes gubernamentales y privadas (2016)
◾ Ciberataques y ciberataques llevados a cabo por Rusia contra periodistas en el New York
Times y otras organizaciones de noticias de EE. UU. (2016)
◾ Ciberataques orquestados por Rusia contra el Comité Nacional Demócrata y el
Comité de Campaña del Congreso Demócrata, para interrumpir o desacreditar a la presidencia
elección (2016)
◾ Ciberataques contra instituciones financieras estadounidenses (por ejemplo, American Express, JP Morgan Chase,
etc.) instigados por los gobiernos de Irán y Corea del Norte (2013)
◾ Ciberataques e infracciones cibernéticas denunciadas por un grupo de hackers sirios en organizaciones de medios
(New York Times, Twitter y The Huffington Post) (2013)
Lo anterior representa solo algunos de los ataques ciberterroristas perpetrados contra el gobierno y
Entidades privadas. Se incluye un resumen de todas las leyes federales de EE. UU. Descritas en esta sección.
en el cuadro 2.3.
Leyes estatales
La legislación de TI a nivel estatal es igualmente relevante para los auditores de TI encargados de examinar aplicaciones,
datos, redes y controles, y el riesgo asociado con el incumplimiento. Descrito abajo
son ejemplos de estas leyes estatales, que incluyen Leyes de notificación de infracciones de seguridad, Ciberseguridad
Legislación, leyes estatales de privacidad en las redes sociales y otras.
En la actualidad, 47 estados, el Distrito de Columbia, Guam, Puerto Rico y las Islas Vírgenes tienen
todos promulgaron leyes de notificación de violaciones de seguridad que requieren entidades en el sector privado, gubernam
Página 74
Figura 2.3 Resumen de las leyes federales de los EE. UU. Relevantes para los auditores de TI
Ley de combate de EE. UU.

Tipo de legislación Delitos informáticos Descripción
Financiero Federal Sarbanes-Oxley • Paquete de reforma importante que exige la mayor

Integridad (SOX) de 2002 cambios de gran alcance que ha impuesto el Congreso
en el mundo empresarial desde el extranjero
Ley de Prácticas Corruptas de 1977 y la Ley de la SEC
de la década de 1930.
• Establece requisitos para las organizaciones
Consejo de Administración, incluida su composición
y deberes.
• Requiere la rotación del auditor (no de la firma auditora).
• Creó la Contabilidad de la Empresa Pública
Junta de Supervisión (PCAOB).
• Prohíbe las firmas contables públicas registradas
de proporcionar clientes de auditoría,
simultáneamente con la auditoría, ciertos
Servicios distintos a los de auditoría.
• Requiere un informe de control interno
incluido como parte del informe anual.
• Exigir que el CEO y el CFO confirmen y
afirmar a las partes interesadas que las divulgaciones de la SEC
son (1) veraces y confiables; y que (2)
la gerencia ha tomado las medidas necesarias
para garantizar que la divulgación de la empresa
los procesos y controles son capaces de
generando información financiera precisa y consistente
información, confiable para las partes interesadas (Sección
302). Las divulgaciones de la SEC incluyen las
estados financieros así como todos
divulgaciones complementarias. De la empresa
El auditor externo también debe informar sobre la
fiabilidad de la evaluación de la dirección de
control interno (Sección 404).
• Penaliza a los CEO, CFO, etc. por
incumplimiento.
Seguridad Federal Fraude informático y • Protege contra la invasión (no autorizada

Ley de abuso de 1984 entrada); exceder el acceso autorizado;
traspaso destructivo intencional e imprudente;
e intercambiando información sobre cómo ganar
Acceso no autorizado.
Seguridad Federal La seguridad informática • Protege la información confidencial en las

Ley de 1987 sistemas gubernamentales.
• Estableció una computadora del gobierno federal
programa de seguridad, NIST, para ayudar en
desarrollo de todo el gobierno, informática
normas, directrices y normas de seguridad del sistema
formación en seguridad.
( Continuacion )
Página 75
Figura 2.3 ( continuación ) Resumen de las leyes federales de EE. UU. Relevantes para los auditores de TI

Seguridad Federal Seguridad nacional • Previene ataques terroristas en los Estados Unidos;
Ley de 2002 reduce la vulnerabilidad de los Estados Unidos
al terrorismo; e incluye la seguridad cibernética
Ley de Mejoramiento, que:
- exige cadenas perpetuas para los piratas informáticos que
arriesgar temerariamente vidas.
- permite recopilar la vigilancia de la red
datos personales y privados (números de teléfono, IP
direcciones, URL, correos electrónicos, etc.) sin un
mandato judicial.
- requiere proveedores de servicios de Internet (ISP)
entregar los registros de los usuarios a la ley
autoridades encargadas de hacer cumplir la ley
legislación actual.
Seguridad Federal Tarjeta de pago • Las PCI DSS son técnicas y operativas
Datos de la industria requisitos que se aplican a las entidades que almacenan,
Estándares de seguridad procesar o transmitir datos del titular de la tarjeta.
(PCI DSS) de 2004 • El objetivo principal de las PCI DSS es
proteger los datos de los titulares de tarjetas para reducir
Fraude de tarjeta de credito.
• Todos los comerciantes que aceptan o procesan
el pago a través de tarjetas debe cumplir con
las PCI DSS.
• Las PCI DSS se mantienen, administran y
promovido en todo el mundo por un PCI Security
Consejo de Normas.
• El Ayuntamiento está formado por las principales tarjetas de crédito
empresas (es decir, American Express, Discover,
JCB International, MasterCard y Visa,
C ª.). Estas empresas comparten igualmente
gobernanza, ejecución y cumplimiento de
el trabajo del Consejo.
Seguridad Federal Información federal • FISMA requiere que las agencias federales desarrollen,
Seguridad documentar y poner en marcha información
Ley de gestión programas de seguridad con el fin de
(FISMA) de 2002 protegiendo tanto la información como la
sistemas / aplicaciones implementadas para
apoyar las operaciones y activos de la
agencias, incluidas las proporcionadas o
administrado por otra agencia, contratista o
otra fuente.
( Continuacion )
Página 76

Seguridad Federal firma electronica • Dos leyes principales con respecto

Leyes de 1999 y a las leyes de firma electrónica son: Uniforme
2000 Ley de Transacciones Electrónicas (UETA) y
Firmas Electrónicas en Global y Nacional
Ley de Comercio (ESIGN).
• UETA, una ley estatal introducida en 1999 y
ya adoptado por 47 estados de EE. UU., el Distrito
de Colombia, Puerto Rico y la Virgen de los Estados Unidos
Islas, valida la firma electrónica
y en cumplimiento de los requisitos legales
cuando las partes estén listas para entrar en un
la transacción ha acordado continuar
electrónicamente.
• ESIGN, una ley federal aprobada en 2000 por el
Congreso de los Estados Unidos, reconoce los
firmas y registros otorgados todo contrato
las partes optan por utilizar documentos electrónicos y
firmarlos electrónicamente.
Intimidad Ley de privacidad de 1974 • Protege a las personas contra la invasión de

su privacidad personal por:
- Permitir a los individuos determinar qué
se recopila información.
- garantizando que la información recopilada sea
sólo se utiliza para un propósito.
- asegurar que la información esté actualizada y
preciso.
Intimidad Comunicaciones electrónicas • Prohíbe (1) la interceptación / divulgación de cables,

Ley de privacidad de 1986 comunicaciones orales o electrónicas; y 2)
fabricación o posesión de interceptar
dispositivos.
Intimidad Comunicaciones • Prohíbe la realización de actos indecentes o evidentes

Acto de decencia de material ofensivo a disposición de los menores a través de
1996 Red de computadoras.
• Los empleadores no son responsables de las acciones de un
empleado a menos que esté dentro del alcance de
su empleo.
Intimidad Niños en línea • Se aplica a la recopilación en línea de datos personales

Protección de privacidad información de niños menores de 13 años.
Ley de 1998 • El acto define específicamente qué personal
la información es para un niño.
( Continuacion )
Página 77

Intimidad Seguro de salud • Protege la confidencialidad y seguridad de

Portabilidad y información sanitaria (por ejemplo,
Ley de responsabilidad registros médicos, información de salud
(HIPAA) de 1996 proporcionado a médicos, hospitales).
• Restringe a las aseguradoras a rechazar a los trabajadores según
condiciones de salud preexistentes; requiere
seguridad y privacidad para proteger personal
información.
Intimidad La salud • Promueve la adopción y uso significativo

Información de TI para la salud en los Estados Unidos.
Tecnología para • Proporciona al Departamento de Salud de EE. UU. Y
Económico y Servicios Humanos con autoridad para
Salud Clínica de establecer programas para mejorar la salud
2009 calidad, seguridad y eficiencia a través de la
"Uso significativo" y promoción de
salud IT.
• El uso significativo se refiere al mínimo
estándares gubernamentales para el uso de
registros de salud e intercambio de datos de pacientes
entre proveedores de atención médica, atención médica
proveedores y aseguradoras, y atención médica
proveedores y pacientes.
Intimidad Gram-Leach-Bliley • Requiere que las instituciones financieras evalúen,

Ley de 1999 gestionar y controlar el riesgo; supervisar el servicio
proveedores; y ajustar los programas de seguridad
basado en el riesgo.
Intimidad Ley Patriota de EE. UU. • Disuade y castiga los actos terroristas en el
2001 Estados Unidos y alrededor del mundo.
• Mejora la investigación policial
herramientas, entre otras.
y / o industrias educativas para notificar a las personas sobre violaciones de seguridad que involucren
su PII. Normalmente, las leyes sobre violaciones de seguridad involucran las siguientes disposiciones:
◾ ¿Quién debe cumplir con la ley (por ejemplo, empresas, corredores de datos / información,
entidades, etc.)
◾ ¿Cómo se define la "información personal" (p. Ej., Nombre combinado con números de seguro social,
licencia de conducir o identificación estatal, números de cuenta, etc.)
◾ Qué constituye una brecha de seguridad (p. Ej., Adquisición no autorizada de datos)
Página 78
◾ Requisitos para la notificación (por ejemplo, tiempo o método de notificación, quién debe ser notificado)
◾ Exenciones (por ejemplo, para información encriptada)
La legislación sobre ciberseguridad es otro ejemplo de leyes estatales vigentes para proteger contra las amenazas cibernética
y sus vastas implicaciones para la seguridad del gobierno y la industria privada, la prosperidad económica y
seguridad Pública. Los estados han empleado legislación con un número significativo de enfoques para tratar
específicamente con la ciberseguridad. Ejemplos de estos métodos incluyen exigir a las agencias gubernamentales
establecer prácticas de seguridad y ofrecer incentivos a la industria de la ciberseguridad. Adicional
Los procedimientos para combatir la ciberseguridad incluyen exenciones de las leyes de registros públicos para
información de seguridad y la creación de comisiones, estudios o grupos de trabajo de ciberseguridad para promover
la educación en ciberseguridad.
Otras leyes estatales comunes y relevantes incluyen leyes estatales de privacidad de redes sociales, eliminación de datos
Leyes y estatutos sobre delitos informáticos. Con respecto a las redes sociales, la legislación estatal se introdujo en
2012 para evitar que los empleadores soliciten contraseñas para cuentas personales de Internet (incluidas
cuentas de redes sociales) para obtener o mantener un trabajo. Una legislación similar prohíbe las universidades y
Versiones de requerir acceso a las cuentas de redes sociales de los estudiantes. El razonamiento aquí fue que tanto,
empleados y estudiantes, consideraron tales solicitudes como una invasión a su privacidad. Eliminación de datos
Se han promulgado leyes en al menos 31 estados y Puerto Rico que exigen que las empresas y el gobierno
entidades para disponer de toda la PII recopilada y almacenada, tanto en formato electrónico como en papel. Específicament
Para cumplir con las leyes establecidas, las empresas y el gobierno deben “destruir, eliminar o
de lo contrario, hacer que la información personal sea ilegible o indescifrable ". Por último, las estadísticas sobre delitos info
utes están en su lugar para prohibir "acciones que destruyan o interfieran con el funcionamiento normal de una computadora
sistema ”, como hackear, obtener acceso no autorizado sin consentimiento y configurar o transmitir
ting instrucciones maliciosas de la computadora (por ejemplo, virus informáticos, malware, etc.) para modificar, dañar,
o destruir registros de información dentro de un sistema informático o red sin el permiso
del propietario.
Leyes internacionales de privacidad
La protección de datos se trata de salvaguardar dicha información privada, que se recopila,
procesados y almacenados por medios electrónicos, o destinados a formar parte de sistemas de archivo. Datos
Deben existir leyes de protección para controlar y dar forma a tales actividades, especialmente las realizadas
por empresas y gobiernos. Estas instituciones han demostrado una y otra vez que, a menos que las reglas
y las leyes restringen sus acciones, intentarán recopilar, examinar y conservar todos esos datos
sin notificar adecuadamente a las personas sobre dicho uso y propósito de acceder a su
datos.
A partir de 2014, más de 100 países de todo el mundo han promulgado protección de datos o privacidad.
leyes, y varios otros países están en proceso de aprobar dicha legislación. Por ejemplo, el
La Unión Europea ha implementado algunas de las políticas de privacidad de datos más sólidas y completas
leyes (es decir, la Directiva de protección de datos de 1995). Canadá es otro ejemplo destacado con la legislación
ción tanto a nivel nacional como provincial (por ejemplo, protección de información personal y
Ley de Documentos de 2000, etc.). El Cuadro 2.4 resume estos y otros datos internacionales relevantes
leyes de protección y privacidad como la Ley de Protección de Datos Personales en Posesión de
Partes de 2010 y la Ley de Puerto Seguro de 1998.
Página 79
Figura 2.4 Resumen de las leyes de privacidad internacionales relevantes para los auditores de TI
Legislación internacional de privacidad Breve descripción
Protección de información personal Uno de los principales propósitos de PIPEDA es apoyar y

y Ley de Documentos Electrónicos promover el comercio electrónico mediante la "protección personal
de 2000 (Ley PIPED, o información que se recopila, utiliza o divulga en determinados
PIPEDA) —Canada circunstancias." a Los siguientes 10 principios, establecidos
por PIPEDA, rigen la recopilación, uso y divulgación de
información personal b :
1. Responsabilidad
2. Identificación de propósitos
3. Consentimiento
4. Limitación de la colección
5. Limitación de uso, divulgación y retención
6. Precisión
7. Salvaguardias
8. Apertura
9. Acceso individual
10. Desafiando el cumplimiento
Ley de Protección de La ley exige que las organizaciones empresariales mexicanas (también
Datos personales en poder de privados como cualquier empresa que opera o publicita en México o
Partes de 2010 — México utiliza centros de llamadas en español y otro tipo de soporte
servicios ubicados en México) para tener consentimiento o
obligación legal para / al recolectar, procesar, usar,
y divulgación de información de identificación personal (PII).
Las organizaciones que se ocupan de la PII deben informar a las personas
sobre dicho uso y, lo más importante, proporcionar
notificación a todas las personas afectadas en caso de
violación de la seguridad. b La ley también incluye ocho
principios que las organizaciones empresariales mexicanas deben
seguir al tratar datos personales c :
• Legalidad
• Consentimiento
• Darse cuenta
• Calidad
• Limitación de propósito
• Fidelidad
• Proporcionalidad
• Responsabilidad
Datos de la Unión Europea La Directiva establece límites rigurosos a la recogida

Directiva de protección de 1995 y uso de datos personales, y exige que cada
instituto del estado miembro un organismo nacional independiente
responsable de la protección de dichos datos. b El
La Directiva afecta a las empresas europeas (así como a
empresas no europeas a las que se exportan datos),
e incluye los siete principios rectores descritos
debajo de d :
( Continuacion )
Página 80
Figura 2.4 ( continuación ) Resumen de las leyes de privacidad internacionales relevantes para los auditores de TI
Legislación internacional de privacidad Breve descripción
Datos de la Unión Europea 1. Debe notificarse a todos los interesados afectados

Directiva de protección de 1995 cuando se recopilan sus datos.
2. Los datos solo deben usarse para el propósito indicado.
3. Los datos no deben divulgarse sin la autorización del sujeto
consentimiento .
4. Los datos recopilados deben mantenerse a salvo de cualquier
abusos potenciales.
5. La divulgación de quién recopila los datos debe ser
proporcionado a todos los interesados afectados.
6. Los interesados deben poder acceder a sus datos.
y hacer correcciones a cualquier dato inexacto.
7. Los interesados deben tener un método disponible para
recolectores de datos asimiento responsables para el seguimiento de estos
seis principios anteriores.
Ley de puerto seguro de 1998 Según la ley, la transferencia de datos personales a países no europeos
Naciones de la Unión (por ejemplo, empresas estadounidenses) que no cumplen con
el estándar europeo de "adecuación" para la protección de la privacidad
(establecido por la protección de datos de la Unión Europea
Directiva) está prohibido. La Ley (específicamente relacionada con EE. UU.
empresas que hacen negocios en Europa) estaba destinado a
unir los diferentes enfoques de privacidad del
Estados Unidos y Europa, lo que permite a las empresas estadounidenses
participar de manera segura en transacciones transatlánticas sin enfrentar
interrupciones o incluso procesamientos por parte de las autoridades europeas. segundo
Algunos requisitos o disposiciones clave de la Ley incluyen h :
• Las empresas que participan en el puerto seguro serán
consideradas adecuadas, y los flujos de datos a esas empresas
continuará.
• Requisitos de los estados miembros para la aprobación previa de datos
las transferencias serán renunciadas o la aprobación será
concedido automáticamente.
• Reclamaciones presentadas por ciudadanos europeos contra EE. UU.
empresas serán escuchadas en los Estados Unidos, sujeto
a excepciones limitadas.
Nota: una lista de otras leyes de privacidad internacionales relevantes,

segregado por país y región, se puede encontrar en
https://informationshield.com/free-security-policy-tools/
leyes-internacionales-de-privacidad-de-datos /
a www.parl.gc.ca/HousePublications/Publication.aspx?Pub=Bill&Doc=C-6&Language=E&Mode
= 1 & Parl = 36 & Ses = 2 & File = 35.
b www.csoonline.com/article/2126072/compliance/the-security-laws--regulations-and-guide-
lines-directory.html? page = 4.
c www.dof.gob.mx/nota_detalle.php?codigo=5150631&fecha=05/07/2010.
d http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2001:008:0001:0022:EN:PDF.
e http://europa.eu/rapid/pressReleasesAction.do?reference=IP/00/865&format=HTML&aged=1
& language = EN & guiLanguage = en.
Página 81
Conclusión
Las operaciones comerciales están cambiando a un ritmo rápido debido a la rápida mejora continua
de tecnología. Internet en particular ahora incluye todo, desde marketing, ventas y
fines de entretenimiento al correo electrónico, la investigación y el comercio, y prácticamente cualquier otro tipo de
el intercambio de información. Al igual que con cualquier avance tecnológico, los avances también han dado
plantean varios problemas nuevos y cuestiones de delitos informáticos que deben abordarse. Estos problemas
a menudo se señalan a la atención del especialista en control y auditoría de TI. Legislación
debe estar en el lugar para gobernar el uso y mal uso de TI, incluida la seguridad y privacidad de la
información.
Se cree que la legislación federal ha tenido un impacto duradero en la comunidad en línea (gobierno
el gobierno, las empresas y el público), que es algo que aquellos que ingresan a la auditoría de TI y
la profesión de aseguramiento de la información debe conocer. Legislación federal de integridad financiera
ción, como la SOX de 2002, cambió drásticamente el mundo de la auditoría financiera, destacando la
importancia del debido cuidado profesional. Asimismo, se implementó la legislación federal de seguridad para
evitar que los delincuentes escapen de las sanciones por violar el acceso autorizado a un sistema informático.
Con respecto a la legislación sobre privacidad, el gobierno de los EE. UU. Promulgó la Ley de Privacidad de 1974 para prop
ciertas garantías para un individuo contra una invasión de la privacidad personal. El acto también coloca
ciertos requisitos de las agencias federales.
El auditor de TI no puede ignorar las leyes tanto a nivel estatal como internacional. Auditores de TI
debe estar familiarizado con esta legislación específica y asegurarse de que los procedimientos estén en su lugar cuando el e
ining aplicaciones, datos, redes y controles, por ejemplo, con el fin de abordar los riesgos y cumplir
con estas leyes de TI relevantes.
1. Resuma las tres categorías principales de delitos que involucran computadoras.
2. ¿Qué prohíbe la Ley Sarbanes-Oxley (SOX) de 2002? ¿Qué requiere SOX de
¿la Junta Directiva?
3. ¿Qué es la Ley de Abuso y Fraude Informático (CFAA) de 1984?
4. ¿Cuál es el propósito de la Ley de seguridad informática de 1987 y qué protege?
5. ¿Por qué se creó la Ley de Seguridad Nacional? ¿Pueden los piratas informáticos que causen lesiones o la muerte
otros serán procesados bajo esta ley? Por favor elabora.
6. Diferenciar entre la Ley Uniforme de Transacciones Electrónicas (UETA) y la
Ley de Firmas Electrónicas en el Comercio Nacional y Global (ESIGN). Proporcione ejemplos
de transacciones específicas en las que una firma electrónica puede ser válida según la legislación estadounidense.
Sugerencia: para esto, debe revisar los requisitos para una firma electrónica válida que se enumeran
en el capítulo.
7. ¿Qué es la Ley de Privacidad de 1974? ¿Qué requisitos impone a las agencias federales?
8. ¿Qué es la Ley de Privacidad de Comunicaciones Electrónicas de 1986 y qué prohíbe?
9. ¿A qué se aplica la Ley de protección de la privacidad infantil en línea de 1998? Que factores
¿Considera la Comisión Federal de Comercio (FTC) para determinar si un sitio web es
dirigido a niños?
10. ¿Qué significa HIPAA y qué protege? Enumere los tres factores que deben estar en
lugar para cumplir con HIPAA.
11. ¿Por qué se implementó la Ley USA PATRIOT de 2001?
Página 82
Ejercicios
1. Con un navegador web de Internet, busque y examine cinco sitios web sobre cada uno de los temas siguientes.
En un formato de tabla de tres columnas, documente el nombre del sitio web examinado en la primera
columna, el enlace de la fuente en la segunda columna y un breve resumen de la información
proporcionado por el sitio web en la tercera columna.
a. Crimen informático
segundo. Privacidad informática
C. Derecho informático
2. Explique por qué cree que es importante que los auditores de TI conozcan cada tipo de legislación.
abajo. Su explicación para cada tipo de legislación no debe tener menos de tres párrafos.
gráficos e incorporar ejemplos de apoyo. También se le anima a buscar
fuentes externas.
a. Legislación Federal
segundo. Legislación estatal
C. Legislación internacional
3. Usted fue contratado como consultor por un cliente que acababa de comenzar a hacer negocios. Algunos de los
Los servicios que brinda su cliente incluyen almacenamiento, procesamiento y / o transmisión de tarjetas de crédito.
datos. Su cliente desconoce las leyes o regulaciones relacionadas con los servicios antes mencionados.
Sabe desde el principio que su cliente debe cumplir con los estándares PCI DSS. Utilizando
un formato de nota, prepare la comunicación a su cliente, incluyendo lo siguiente:
a. Resuma qué son las PCI DSS y por qué son relevantes para su cliente. Eres muy
Animado a buscar fuentes externas.
segundo. Usar los seis objetivos y requisitos (viñetas) de PCI DSS enumerados en el capítulo
como objetivos, desarrolle un plan para cumplir con cada objetivo. Su plan debe incluir los
objetivo junto con una breve explicación de la actividad o procedimiento que le aconsejará
su cliente a implementar con el fin de cumplir con el objetivo específico. Por ejemplo, para
una de las metas u objetivos, "Protección de los datos almacenados del titular de la tarjeta", debe explicar
cómo se protegerán específicamente los datos del titular de la tarjeta y qué técnicas de cifrado
debe ponerse en práctica (es posible que desee ampliar aquí ya que su cliente había expresado a
usted que no está muy familiarizada con la tecnología). En definitiva, tu comunicación
debe brindar comodidad a su cliente y garantizar que todas las transmisiones de datos del titular de la tarjeta
de hecho están salvaguardados.
4. Identifique dos ciberataques recientes (no mencionados en el libro) realizados en el
Estados Unidos o internacionalmente. Resuma ambos ciberataques de acuerdo con la Figura 2.2
(es decir, la descripción de la empresa, la industria y el ciberataque) y prepárese para presentarlos al
clase en una presentación de 5 minutos.
Otras lecturas
1. Autor desconocido. (Marzo de 2016). Informe sobre delitos en Internet de 2009 , Centro de quejas sobre delitos en Internet IC3,
pags. 14, www.ic3.gov/media/annualreport/2009_IC3Report.pdf (consultado el 2 de junio de 2010).
2. Autor desconocido. (Marzo de 2016). Esfuerzos del Departamento de Justicia para combatir el robo de identidad , EE. UU.
Oficina del Inspector General del Departamento de Justicia, www.justice.gov/oig/reports/plus/a1021.pdf
(consultado el 2 de junio de 2010).
3. CIPHER — Boletín electrónico del Comité Técnico de Seguridad y Privacidad, A
Comité de la Sociedad de Informática del IEEE, www.ieee-security.org/cipher.html
Página 83
4. División de seguridad informática, Centro de recursos de seguridad informática. NIST, http://csrc.nist.gov/groups/

SMA / fisma / overview.html (consultado en octubre de 2016).
5. Estatutos sobre delitos informáticos. Conferencia Nacional de Legislaturas Estatales, www.ncsl.org/research/tele-
comunicaciones-e-tecnología-de-la-información / piratería-informática-y-leyes-de-acceso-no-autorizado.
aspx (consultado en enero de 2017).
6. Violación de la confidencialidad: el hospital envió los registros de los pacientes al taller de automóviles. Questex LLC, www.fier
com / story / confidenciality-breach-hospital-sent-patient-records-auto-shop / 2010-06-28 (consultado en enero
2017).
7. Legislación en ciberseguridad. (2016). Conferencia Nacional de Legislaturas Estatales, www.ncsl.org/research/
Telecommunications-and-Information-Technology / Cybersecurity-Legislation-2016.aspx (consultado
Octubre de 2016).
8. China continúa con los ataques cibernéticos a las redes estadounidenses. The Washington Free Beacon , http: // freebeacon.
com / national-security / china-continue-cyber-attack-on-us-networks / (consultado en octubre de 2016).
9. Leyes de eliminación de datos. Conferencia Nacional de Legislaturas Estatales, www.ncsl.org/research/telecommuni-
cations-and-information-technology / data-disposition-law.aspx (consultado en octubre de 2016).
10. Protección de datos. Privacy International, www.privacyinternational.org/topics/data-protection (consultado
Noviembre de 2016).
11. Oficina Federal de Investigaciones. Los delincuentes alojan sitios web falsos de servicios gubernamentales para adquirir persona
Información de identificación personal y para cobrar tarifas fraudulentas, Anuncio de servicio público. www.ic3.
gov / media / 2015 / 150407-2.aspx (consultado en diciembre de 2015).
12. Gallegos, F. (2001). Leyes federales que afectan a los profesionales de auditoría y control de SI , Serie de auditoría de EDP
# 72-10-20, Auerbach Publishers, Boca Raton, FL, págs. 1-20.
13. Legislación y normativa de tecnologías de la información sanitaria. HealthIT.gov, https://www.healthit.gov/topic/laws-regulation
and-policy / health-it -law (consultado en octubre de 2016).
14. Hathaway, OA, Crootof, R., Levitz, P., Nix, H., Nowlan, A., Perdue, W. y Spiegel, J. La ley de
ataque cibernetico. California. L. Rev. , 100 (4), 817–885. www.jstor.org/stable/23249823
15. Herath, T. y Rao, HR (2009). Fomentar comportamientos de seguridad de la información en las organizaciones:
Papel de las sanciones, presiones y efectividad percibida. Decis. Soporte Syst. , 47 (2), 154-165.
16. Regla final provisional de aplicación de la ley HITECH. Departamento de Salud y Servicios Humanos de EE. UU.,
www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/
(consultado en noviembre de 2016).
17. Recursos legales de HG.org. Ley de tecnología de la información: Guía de la ley de TI, www.hg.org/information-
technology-law.html # 1 (consultado en octubre de 2016).
18. Comisión Federal de Comercio, (2002). Cómo cumplir con la privacidad de la información financiera del consumidor
regla de mación de la Ley Gramm-Leach-Bliley. www.ftc.gov/tips-advice/business-center/guidance/
cómo-cumplir-privacidad-consumidor-información-financiera-regla-gramm # whois
19. Inserra, D. 69º complot terrorista islamista: el aumento continuo del terrorismo debería obligar al Congreso a enfrentarse finalm
amenaza terrorista . The Heritage Foundation, www.heritage.org/research/reports/2015/06/69th-islamist-
Terrorista-complot-en-curso-pico-en-terrorismo-debería-forzar-al-Congreso-a-finalmente-confrontar-al-terrorista-
amenaza
20. Uso significativo. Tech Target, http://searchhealthit.techtarget.com/definition/meaningful-use
21. Privacidad médica: estándares nacionales para proteger la privacidad de la información médica personal, www.
hhs.gov/ocr/hipaa/
22. New York Times, Twitter pirateado por un grupo sirio. The Daily Star , www.thedailystar.net/news/new-
york-times-twitter-hacked-by-syrian-group (consultado en febrero de 2016).
23. Seguridad PCI. PCI Security Standards Council, www.pcisecuritystandards.org/pci_security/ (consultado
Diciembre de 2016).
24. Privacidad. Glosario de términos de ISACA®, www.isaca.org/Knowledge-Center/Documents/Glossary/glossary.pdf
25. Ley de privacidad de 1974 y enmiendas, documento del Archivo de información / privacidad de la CPSR,
https://epic.org/privacy/1974act/
26. Pautas de privacidad para la revisión de NII de los principios propuestos del Grupo de trabajo de privacidad, compilado
por Electronic Privacy Information Center, www.epic.org
Página 84
27. Rusia sospechosa de ciberataques a medios de comunicación estadounidenses. New York Post , http://nypost.com/2016/08/23/
russia-sospechos-in-cyber-attack-on-us-news-outlets / (consultado en agosto de 2016).
28. Sarbanes – Oxley-101. Sección 302: Responsabilidad corporativa por informes financieros, www.sarbanes-
oxley-101.com/SOX-302.htm (consultado en agosto de 2016).
29. Sarbanes – Oxley-101. Sección 404: Evaluación administrativa de controles internos, www.sarbanes-
30. Leyes de notificación de infracciones de seguridad. Conferencia Nacional de Legislaturas Estatales, www.ncsl.org/research/
telecomunicaciones-y-tecnología-de-la-información / leyes-de-notificación-de-incumplimiento-de-seguridad.aspx # 1 (consultad
Octubre de 2016).
31. Senft, S., Gallegos, F. y Davis, A. (2012). Control y auditoría de tecnologías de la información , CRC Press /
32. Conferencia Nacional de Legislaturas Estatales. Leyes estatales de privacidad de las redes sociales, www.ncsl.org/research/
telecomunicaciones-y-tecnología-de-la-información / leyes-estatales-que prohíben-el-acceso-a-las-redes-sociales-
usernames-and-passwords.aspx (consultado en octubre de 2016).
33. Ley UETA y ESIGN. DocuSign Inc, www.docusign.com/learn/esign-act-ueta (consultado en diciembre
2016).
34. Congreso de Estados Unidos. Ley de seguridad informática de 1987, compilada por el Centro de información de privacidad elect
www.epic.org/crypto/csa
35. Departamento de Salud y Servicios de EE. UU. Oficina de Derechos Civiles — HIPAA, http://aspe.hhs.gov/
admnsimp / pL104191.htm
36. Departamento de Justicia de Estados Unidos, Oficina Federal de Investigaciones. 2016. Informe sobre delitos en Internet, https: /
ic3.gov/2016_IC3Report.pdf (consultado en noviembre de 2016).
37. Departamento de Justicia de los Estados Unidos, Oficina Federal de Investigaciones. 2015. Informe sobre delitos en Internet, http
ic3.gov/2015_IC3Report.pdf (consultado en diciembre de 2015).
38. Departamento de Justicia de Estados Unidos, Oficina Federal de Investigaciones. 2014. Informe sobre delitos en Internet, https: /
ic3.gov/2014_IC3Report.pdf (consultado en diciembre de 2015).
39. Departamento de Justicia de los Estados Unidos, Oficina de Programas de Justicia, Oficina de Asistencia Judicial. Gobierno elec
Ley de 2002, www.it.ojp.gov/PrivacyLiberty/authorities/statutes/1287 (consultado en junio de 2013).
40. Estados
article /Unidos acusa formalmente a los piratas informáticos
us-usa-cyber-russia-idUSKCN12729B rusos
(consultado en de ciberataques
diciembre de 2016).políticos. Reuters, www.reuters.com/
41. Oficina de Responsabilidad del Gobierno de Estados Unidos. (14 de febrero de 2008). Testimonio ante el Congreso
Subcomités de Seguridad de la Información.
Página 85
Capítulo 3
El proceso de auditoría de TI
1. Describa qué es el universo de auditoría e ilustre un ejemplo.
2. Definir los objetivos de control para la información y la tecnología relacionada y explicar por qué son
útil para organizaciones y auditores.
3. Explique qué es una evaluación de riesgos y su importancia para la función de auditoría. Ilustra un
ejemplo de una evaluación de riesgos siguiendo el Instituto Nacional de Estándares y Tecnología
metodología.
4. Describa un plan de auditoría y sus componentes. Ilustre ejemplos de documentación de auditoría de TI
respaldar una auditoría de estados financieros.
5. Defina el proceso de auditoría y describa las fases de un trabajo de auditoría de TI.
6. Analice otros tipos de auditorías realizadas en TI.
El papel de la auditoría de TI sigue siendo un mecanismo crítico para garantizar la integridad de la información.
sistemas de información y la presentación de informes de las finanzas de la organización para evitar futuros fiascos financier
como Enron (2001) y WorldCom (2002). Desafortunadamente, estos fiascos continúan ocurriendo. Global
las economías son más interdependientes que nunca y los riesgos geopolíticos afectan a todos. Electrónico
la infraestructura y el comercio están integrados en los procesos comerciales de todo el mundo. La necesidad de
el control y la auditoría de TI nunca ha sido tan grande.
El auditor de TI de hoy se enfrenta a muchas preocupaciones sobre la exposición de los sistemas de información a
una multitud de riesgos. De estas preocupaciones surgen los objetivos para el proceso y la función de auditoría.
Este capítulo analiza el proceso de auditoría para TI y las demandas que se le impondrán al profesorado.
sion en el futuro.
Universo de auditoría
Una de las mejores prácticas para una función de auditoría es tener un universo de auditoría. El universo de auditoría es un
Inventario de todas las áreas de auditoría potenciales dentro de una organización. Áreas de auditoría funcional básica dentro
una organización incluye ventas, marketing, servicio al cliente, operaciones, investigación y desarrollo,
finanzas, recursos humanos, tecnología de la información y legal. Un universo de auditoría documenta la clave
59
Página 86
procesos de negocio y riesgos de una organización. Documentar procesos y, en particular, riesgos

han demostrado ser una buena práctica para las organizaciones. La Norma de Desempeño 2010 del IIA fomenta
envejece el establecimiento de planes basados en riesgos para determinar las prioridades de la actividad de auditoría interna.
Un universo de auditoría incluye el área de auditoría funcional básica, los objetivos de la organización, los negocios clav
procesos que apoyan los objetivos de la organización, objetivos específicos de auditoría, riesgos de
lograr esos objetivos y controles que mitiguen los riesgos. Vincular el universo de la auditoría a la organización
Los objetivos nacionales vinculan todo el proceso de auditoría con los objetivos y riesgos comerciales, lo que facilita la
comunicar el impacto de las deficiencias de control. La figura 3.1 muestra un ejemplo de un universo de auditoría
relacionado con el área de TI de una organización.
El universo de la auditoría también es un componente esencial para una auditoría interna basada en riesgos adecuadame
proceso. Por lo general, los grupos de auditoría interna preparan programas anuales de auditoría para determinar el número
de horas disponibles y el número de auditorías que se pueden realizar. El universo de la auditoría es un
proceso de ing; a medida que cambia una organización, surgen nuevos riesgos o cambian los riesgos existentes, y
se introducen ciones. Las organizaciones pueden eliminar las auditorías de menor prioridad del programa o
contratar auditores externos para complementar al personal interno.
Las auditorías de TI, por ejemplo, tienen procesos de TI específicos para incluir en el universo de auditoría. Controlar
Objectives for Information and Related Technology (COBIT) proporciona una lista completa de
procesos críticos de TI, que se pueden utilizar como punto de partida.
COBIT
COBIT es un conjunto internacional autorizado de prácticas de TI u objetivos de control generalmente aceptados.
tivos que ayudan a los empleados, gerentes, ejecutivos y auditores a: comprender los sistemas de TI,
cobrar responsabilidades fiduciarias y decidir los niveles adecuados de seguridad y controles.
COBIT apoya la necesidad de investigar, desarrollar, publicitar y promover la actualización internacional
objetivos de control de TI aceptados tradicionalmente. El énfasis principal del marco COBIT emitido
por la Information Systems Audit and Control Foundation en 1996 es asegurar que la tecnología
Proporciona a las empresas información relevante, oportuna y de calidad para la toma de decisiones. los
El marco de COBIT, ahora en su quinta edición (COBIT 5), ha evolucionado a lo largo de los años y cada vez
hay cambios importantes en el marco, el marco está numerado a su versión actual.
El beneficio de un marco estándar para controles de TI, como COBIT, es que permite la gestión
ment para comparar su entorno y compararlo con otras organizaciones. Los auditores de TI también pueden
utilizar COBIT para fundamentar sus evaluaciones y opiniones de control interno. Porque el marco
El trabajo es completo, proporciona garantías de que existen controles y seguridad de TI.
COBIT 5, que se puede descargar de www.isaca.org, ayuda a las organizaciones a crear
valor de TI manteniendo un equilibrio entre obtener beneficios y optimizar los niveles de riesgo y
Uso de recursos. COBIT 5 se basa en cinco principios (consulte el Cuadro 3.2). COBIT 5 considera las necesidades de TI
de las partes interesadas internas y externas (Principio 1), al tiempo que cubre completamente el gobierno de la organización
nanciamiento y gestión de la información y tecnología relacionada (Principio 2). COBIT 5 proporciona una
marco integrado que se alinea e integra fácilmente con otros marcos (por ejemplo, Comité de
Organizaciones patrocinadoras de la Comisión Treadway-Enterprise Risk Management (COSO-
ERM), etc.), estándares y mejores prácticas utilizadas (Principio 3). COBIT 5 permite que la TI se gobierne
y gestionado de manera integral para toda la organización (Principio 4) a través de:
a. Establecer principios, políticas y orientaciones prácticas para la gestión diaria.

segundo. Implementar procesos para lograr metas y objetivos generales relacionados con TI.
Página 87
El proceso de auditoría de TI ◾ 61
Figura 3.1 Ejemplo de un universo de auditoría relacionado con el área de TI de una organización
Área de auditoría funcional básica: Tecnología de la información

Organización ' s Objetivo: Proporcionar un acceso seguro a la información financiera, la tecnología y
servicios para todos los empleados autorizados.
Negocio clave
Proceso Objetivo de auditoría de TI Riesgo de TI Control de mitigación de TI
Acceso La seguridad del sistema es Los usuarios poseen privilegios Privilegios de acceso de usuario
Controlar adecuadamente que no son consistentes son periódicamente
administración implementado, con sus funciones laborales, revisado por
administrado, y permitiendo así propietarios de aplicaciones
registrado para salvaguardar no autorizado o para verificar el acceso
contra no autorizado modificaciones incorrectas los privilegios permanecen
acceso ao a financiero o apropiado y
modificaciones de datos contables, que consistente con el trabajo
programas y datos, Podría causar requisitos.
que resultan en segregación de deberes
incompleto, conflictos, no prevenidos
inexacto o inválido o errores no detectados,
procesamiento o finanzas incorrectas, o
registro de finanzas las decisiones de gestión
información. basado en engañoso
información.
Cambio Programas y sistemas Desarrolladores o Sistemas de aplicación,

Controlar son apropiadamente los programadores tienen el bases de datos, redes,
administración implementado en un capacidad para promover y operando
manera de apoyar incorrecto o los sistemas son
el preciso inapropiado desarrollado, modificado,
completo y válido modificaciones o y probado en un
procesamiento y cambios en las finanzas ambiente separado
registro de finanzas datos, programas o de la producción
información. ajustes en el medio ambiente. Acceso
procesamiento de producción al desarrollo
medio ambiente, así y prueba
resultando en inválido entornos es
datos contables y / o adecuadamente
fraude. restringido.
administración Los datos están apropiadamente Informes financieros Las copias de seguridad se archivan
de datos logró proporcionar información y fuera del sitio para minimizar
Centrar, Garantía razonable los datos contables no pueden riesgo de pérdida de datos.
Red, esos datos financieros ser recuperado en el
y apoyo permanecer completo, caso de falla del sistema,
exacto y válido impactando la entidad
durante el capacidad para informar
actualización y almacenamiento información financiera
proceso. de acuerdo a
informes establecidos
requisitos.
Página 88
1. Reunión
Interesado
necesidades
5. Separación
2. Cubriendo el
gobernancia
fin de empresa
desde
para terminar
administración
3. Aplicar un
4. Habilitación de
soltero,
holístico
integrado
Acercarse
marco de referencia
Figura 3.2 Principios del marco de COBIT 5. (Adaptado de http://www.isaca.org/cobit/

pages / cobit-5-framework-product-page.aspx.)
C. Poner en marcha estructuras organizativas con capacidades clave para la toma de decisiones.
re. Promover la buena cultura, la ética y el comportamiento en la organización.
mi. Reconocer que la información es omnipresente en cualquier organización y, a menudo,
producto clave
F. Teniendo de lalapropia
en cuenta organización.
infraestructura, tecnología y aplicaciones que brindan la
organización con procesamiento y servicios de TI.
gramo. Reconocer que se requieren personas, habilidades y competencias para completar con éxito
ción de todas las actividades y la correcta toma de decisiones.
COBIT 5 ayuda a las organizaciones a separar adecuadamente la gobernanza de los objetivos de gestión
(Principio 5). Tanto la gobernanza como la gestión se describen a continuación.
a. Gobernanza: optimiza el uso de los recursos de la organización para abordar los riesgos de manera eficaz.
El gobierno asegura que la Junta Directiva ("junta"):
yo. evalúa las necesidades de las partes interesadas para identificar objetivos,
ii. orienta la gestión priorizando los objetivos, y
iii. monitorea el desempeño general de la gerencia.
segundo. Gestión: planifica, crea, ejecuta y supervisa las actividades y los procesos que utiliza el
organización para perseguir los objetivos establecidos por la junta.
El marco de COBIT 5 es valioso para organizaciones de todo tipo, incluidas las comerciales, no para
lucro, o en el sector público. El marco integral proporciona un conjunto de objetivos de control
que no solo ayuda a los profesionales de gestión y gobierno de TI a administrar sus operaciones de TI, sino
también auditores de TI en su búsqueda por examinar esos objetivos.
Los procesos de COBIT se pueden personalizar para el entorno de la organización. Auditores de TI
puede ayudar a la gestión de auditoría a identificar las aplicaciones asociadas con el negocio crítico y
Página 89
procesos financieros, así como los controles necesarios para que el área auditada esté libre de
exposiciones significativas al riesgo. Este objetivo también comprende validar la adherencia de la aplicación
sistemas de cation bajo examen de acuerdo con las normas apropiadas (por ejemplo, la contabilidad financiera debe
cumplir con GAAP, etc.).
El siguiente paso en el proceso de planificación es realizar una evaluación de riesgos para cada elemento del universo.
del cuadro 3.1. La evaluación de riesgos analizará las exposiciones y ayudará a priorizar la auditoría de "alto riesgo"
proyectos.
Evaluación de riesgos
Las evaluaciones de riesgos se consideran la base de la función de auditoría, ya que ayudan a desarrollar
el proceso de planificación de auditorías individuales. Específicamente, evaluaciones de riesgo:
◾ mejorar la calidad, cantidad y accesibilidad de los datos de planificación, como áreas de riesgo,
auditorías y resultados e información presupuestaria;
◾ examinar posibles proyectos de auditoría en el universo de auditoría y elegir aquellos que tengan
la mayor exposición al riesgo debe realizarse primero; y
◾ proporcionar un marco para la asignación de recursos de auditoría para lograr los máximos beneficios.
Dado el gran número de auditorías potenciales que se pueden realizar y, a menudo, el limitado
cantidad de recursos de auditoría, es importante centrarse en las auditorías adecuadas. La evaluación de riesgos
El enfoque proporciona criterios explícitos para evaluar y seleccionar sistemáticamente estas auditorías.
En el entorno actual, es difícil mantenerse al día con los cambios organizativos y normativos para
proporcionar información oportuna sobre controles internos. El cambio aumenta el universo de auditoría, el número
de socios comerciales (es decir, proveedores), y el número de proyectos donde un objetivo e independiente
se necesita perspectiva. Un proceso de planificación de la evaluación de riesgos eficaz permite que la auditoría sea más flexi
ible y eficiente para satisfacer las necesidades de una organización cambiante, tales como:
◾ identificar nuevas áreas de riesgo

◾ identificar cambios en áreas de riesgo existentes
◾ acceder a información legal y regulatoria actual
◾ aprovechar la información recopilada durante el proceso de auditoría para mejorar la evaluación de riesgos
Las áreas de auditoría se pueden evaluar mediante un mecanismo de puntuación ponderado. Sin embargo, la gestión de audit
deben evaluar los resultados utilizando su conocimiento de los objetivos y el entorno de la organización para
asegúrese de que las prioridades reflejen la realidad. Las áreas de auditoría también se pueden agrupar para mejorar la eficie
al revisar procesos similares. La función de auditoría es cíclica en el sentido de que utiliza datos históricos y
información actual para la evaluación de riesgos, evalúa controles, comunica resultados e incorpora
califica esos resultados de nuevo en la evaluación de riesgos.
En una evaluación de riesgos de TI, por ejemplo, las aplicaciones financieras son auditorías / proyectos comunes para
ser clasificado. Sus riesgos se pueden identificar, evaluar y priorizar. Los controles (salvaguardas) también son
identificados para ser implementados para abordar y mitigar tales riesgos. Riesgos de TI relacionados con las finanzas
las aplicaciones se pueden identificar mediante:
◾ Auditorías, revisiones, inspecciones

◾ Leer diagramas de flujo de operaciones
Página 90
◾ Uso de cuestionarios de análisis de riesgos

◾ Analizar las tendencias de los estados financieros
◾ Completar listas de verificación de pólizas de seguros
La seguridad absoluta frente a subprocesos y riesgos en los entornos tecnológicos actuales no es realista.
Evaluaciones de riesgo, según el Instituto Nacional de Estándares y Tecnología (NIST)
Publicación especial 800-30, se utilizan para ayudar a las organizaciones a determinar el alcance del potencial
amenazas reales y los riesgos asociados con los sistemas y aplicaciones de TI. Los resultados de lo anterior
ayudar a la gerencia a identificar e implementar controles de TI apropiados para reducir o
eliminar esas amenazas y riesgos durante el proceso de mitigación. NIST recomienda que para
una evaluación de riesgos, es importante que las organizaciones sigan estos pasos:
1. Disponga de un proceso para identificar o caracterizar los activos (por ejemplo, aplicaciones financieras, etc.).
2. Defina las vulnerabilidades de esos activos y las fuentes de amenazas que pueden desencadenarlas.
3. Determine los niveles de probabilidad (p. Ej., Muy alto, alto, medio, etc.) que
pueden ejercitarse las vulnerabilidades. Por ejemplo, probabilidades de muy alta = 1,00, alta = 0,75,
media = 0,50, baja = 0,25 y muy baja = 0,10 pueden asignarse para cada vulnerabilidad
basado en la estimación de la organización de su nivel de probabilidad.
4. Asigne una magnitud de impacto para determinar qué tan sensible puede ser el activo frente al éxito.
amenazas plenamente ejercidas. Normalmente se asignan magnitudes de impacto y valores de nivel de impacto
por la administración para cada amenaza exitosa que pueda ejercer una vulnerabilidad.
5. Asociar activos con TI correspondiente y / o riesgos comerciales.
6. Calcule la clasificación de riesgo multiplicando la probabilidad asignada en el Paso 3 anterior (por ejemplo,
1,00, 0,75, etc.) multiplicado por el valor del nivel de impacto asignado en el Paso 4.
7. Recomendar los controles necesarios para mitigar los riesgos de acuerdo con su prioridad.
ity o ranking.
Depende de la organización determinar cómo lidiar con los riesgos que han identificado: tomar
una oportunidad y vivir con ellos o tomar medidas para proteger sus activos. Al mismo tiempo, deben
considerar los costos asociados con la implementación de controles, su impacto en los usuarios, la mano de obra
necesarios para implementarlos y gestionarlos, y el alcance de la acción. La figura 3.3 muestra una
ejemplo de una evaluación de riesgos de TI realizada para identificar y priorizar los riesgos dentro de las aplicaciones financ
cationes. La evaluación de riesgos se trata con más detalle en un capítulo posterior.
Plan de auditoria
La función de auditoría debería formular planes anuales y a largo plazo. La planificación es una función básica
necesaria para describir lo que se debe lograr, incluir presupuestos de tiempo y costos, y
establecer prioridades de acuerdo con las metas y políticas de la organización. El objetivo de la planificación de la auditoría
optimizar el uso de los recursos de auditoría. Para asignar eficazmente los recursos de auditoría, el departamento de auditorí
Los mentos deben obtener una comprensión integral del universo de auditoría y los riesgos asociados
con cada elemento del universo. No seleccionar los elementos apropiados puede resultar en oportunidades perdidas para
mejorar los controles y la eficiencia operativa. Departamentos de auditoría interna que desarrollan y mantienen
Los archivos del universo de auditoría se proporcionan a sí mismos con un marco sólido para la planificación de la auditoría
La intención del plan de auditoría es proporcionar un enfoque general dentro del cual los encargos de auditoría
se puede realizar. Proporciona la guía para auditar los procesos integrales de la organización.
Página 91
Figura 3.3 Ejemplo de evaluación de riesgos para el área de auditoría funcional de TI
Determinación de probabilidad Impacto
Impacto
Financiero Área de TI / Probabilidad Probabilidad Magnitud Nivel
Solicitud Vulnerabilidad Fuente de amenaza Nivel Asignado de impacto Valor Riesgo
Financiero Operaciones de SI / Huracanes Medio 0,50 Alto 75 Información FA1

Solicitud No hay sistema no puede ser
# 1 (FA1) almacenamiento fuera delfracasos
sitio recuperado en
para datos inesperado el evento de
copias de seguridad a cierres fallo de sistema,
proporcionar impactando el
razonable De la empresa
garantía de capacidad para infor
disponibilidad en financiero
el evento de un información
desastre. de acuerdo a
establecido
reportando
requisitos.
Información No autorizado Alto 0,75 Alto 75 Seguridad

Seguridad / usuarios parámetros
Varios de los (hackers, no son
Comp cualquiera terminado adecuadamente
seguridad lógica empleados, configurado,
configuración (es decir, y conocedores) permitiendo
contraseñas) potencial
configurado para no autorizado
FA1 no son acceso de usuario
consistente con a FA1.
mejor de la industria
prácticas.
Página 92
Figura 3.3 ( continuación ) Ejemplo de evaluación de riesgos para el área de auditoría funcional de TI
Impacto
Financiero Información No autorizado Muy alto 1,00 Alto 75 Los usuarios poseen
Solicitud Seguridad / FA2 usuarios privilegios que
# 2 (FA2) los propietarios no (hackers, no son
periódicamente terminado consistente con
revisar usuario empleados, su trabajo
acceso y conocedores) funciones,
privilegios. permitiendo
no autorizado
o incorrecto
modificaciones
a los datos de FA2,
Cual podría
porque
administración
decisiones
basado en
engañoso
información.
Información No autorizado Muy alto 1,00 Alto 75 Terminado

Seguridad / usuarios los usuarios pueden
Terminado (terminado acceso a FA2
cuentas de usuario empleados) y ver o
no son modificar su
retirado de financiero
FA2. información.
Página 93
Figura 3.3 ( continuación ) Ejemplo de evaluación de riesgos para el área de auditoría funcional de TI
Impacto
Cambio de control No autorizado Bajo 0,25 Alto 75 Los cambios de FA2 s

Administración / solicitud no adecuadamente
Resultados de la prueba para
cambios y autorizado.
Actualizaciones de FA2 modificaciones Implementación
no son de tales cambios
aprobado por podría resultar en
administración, inválido o
antes de su datos engañosos.
implementación
dentro
producción.
a Calculado multiplicando la "Probabilidad asignada" y el "Valor del nivel de impacto".
Página 94
La organización y su dirección deben participar y apoyar plenamente este esfuerzo. Compromiso

se puede obtener si los participantes reconocen que un buen plan puede ayudar a identificar problemas en un
entorno de TI dinámico y automatizado, por ejemplo. Por tanto, debería ser responsabilidad de todos
participantes no solo para ayudar a identificar tales problemas, sino también para ayudar en la medición y
cuantificación de problemas.
Es difícil identificar, medir y cuantificar problemas en el área de TI. El campo de las TI
es tecnológicamente complejo y tiene un lenguaje propio. Participantes en la formulación de un
El plan de auditoría de TI, y en particular los propios auditores de TI, deben tener suficiente experiencia y
Capacitación en asuntos técnicos para poder comprender conceptos clave y abstracciones sobre la aplicación.
sistemas. Por ejemplo, las abstracciones sobre TI pueden incluir aspectos importantes que son susceptibles
a nombrar, contar o conceptualizar. Comprender los sistemas en este nivel puede conducir a la
identificación de las principales áreas problemáticas. La concentración de auditoría, entonces, puede dirigirse a los principal
áreas problemáticas con mayor probabilidad de producir resultados significativos.
Con base en esta identificación de problemas, el auditor de TI determina qué datos adicionales podrían
ser requerido para tomar decisiones de evaluación. El proceso de auditoría, por lo tanto, debe ser lo suficientemente flexible
combinar personal calificado, nueva tecnología y técnicas de auditoría de nuevas formas para adaptarse a cada situación
ación. Sin embargo, esta flexibilidad de enfoque requiere documentación en pasos planificados y dirigidos.
Los sistemas que se entienden mal (o que se han diseñado sin los controles adecuados) pueden
resultar en ingresos perdidos, aumento de costos y tal vez desastre o fraude.
Durante la fase de planificación de la auditoría, el gerente de auditoría de TI debe reunirse con el jefe de información.
oficial de operaciones (CIO) y miembros senior de la administración de TI para obtener sus aportes y su consentimiento
con la evaluación de riesgos de los procesos de TI en el universo de auditoría. Si hay una dirección de TI
mittee, el universo de auditoría también debe revisarse con él. Esto ayudará a asegurar la alineación
entre TI, negocios y auditoría en las áreas clave de riesgo. La reunión con el CIO y los gerentes de TI
También debe presentar al personal de auditoría y comunicar el alcance, objetivos, cronograma, presupuesto y
proceso de comunicación que se utilizará durante todo el trabajo. Esta también es una oportunidad para
discusión abierta de la percepción de la gerencia de TI de las áreas de riesgo, cambios significativos en el área bajo
revisión e identificación de los contactos apropiados en TI.
Un plan de auditoría de TI divide la auditoría en segmentos discretos que describen los sistemas de aplicación.
como una serie de compromisos y pasos de auditoría manejables. En la planificación detallada o el compromiso
nivel, estos segmentos tendrán objetivos personalizados para implementar la organización
metas y objetivos dentro de las circunstancias de la auditoría. Por lo tanto, la auditoría de TI no requiere
Enfoques "enlatados". No existe una sola serie de pasos detallados que se puedan describir una vez y luego
repetido en cada auditoría. El plan de auditoría, por lo tanto, es un intento de proporcionar un enfoque ordenado.
dentro del cual se puede ejercer la flexibilidad. Como mínimo, un plan de auditoría de TI, después de reunir un
Comprensión completa del universo de auditoría y los riesgos asociados con cada elemento del universo,
debería:
1. Enumere los objetivos de la auditoría y describa el contexto.

2. Desarrollar el programa de auditoría
3. Cree el presupuesto de auditoría y defina el alcance
4. Enumere los miembros del equipo de auditoría, describa las tareas de auditoría, determine los plazos
Objetivos y contexto
El objetivo y el contexto del trabajo son elementos clave en cualquier entorno de auditoría y no deben
ser pasado por alto. Son simplemente la base por la cual se deben abordar todas las auditorías. El objetivo
Página 95
es lo que se intenta lograr. El contexto es el entorno en el que se realizará el trabajo.

realizado. Por lo tanto, todo depende en última instancia tanto del objetivo como del contexto del trabajo.
a realizar. Es decir, las decisiones tomadas sobre el alcance, la naturaleza y el momento del trabajo de auditoría.
depende de lo que el auditor esté tratando de hacer (por ejemplo, obtener seguridad de un saldo de cuentas por cobrar
asegurarse de que una aplicación financiera recién implementada funcione correctamente, evaluar si
el sitio web del cliente es seguro, etc.) y el entorno en el que está trabajando (p. ej., una gran empresa frente a una pequeña
empresa, una organización nacional con un sistema centralizado versus una multinacional con múltiples
divisiones, una organización con sede en Nueva York versus una con sede en Dakota del Norte, etc.).
Tenga en cuenta que lo que funciona bien para una organización puede no funcionar tan bien en otra según
muchas combinaciones de objetivo y contexto. Por ejemplo, si el auditor de TI tiene un control general
Evaluación, los objetivos de la auditoría pueden ser verificar que todos los controles que rodean las aplicaciones financieras
ciones y relacionadas con el centro de datos, operaciones de sistemas de información, seguridad de la información y
La gestión del control de cambios es adecuada. Por lo tanto, el auditor de TI necesita verificar los controles
porque los auditores financieros confiaban en dicho sistema informático financiero para proporcionarles
la información financiera correcta. El contexto es donde entran en juego las verdaderas habilidades analíticas del auditor.
tocar. Aquí, el entorno es en su mayor parte siempre diferente de una tienda a otra. El auditor
debe evaluar el contexto para el que ha entrado y tomar una decisión sobre cómo el entorno
Se debe abordar
Al definir loselobjetivos
tema (poryejemplo, gran
el contexto delempresa, pequeña empresa,
trabajo adecuados, gran puede
la dirección personal, personalque
garantizar reducido, etc.).
auditoría verificará el correcto funcionamiento y control de todas las áreas clave de auditoría. Un objetivo común /
El contexto establecido para las auditorías de TI es para respaldar las auditorías de estados financieros.
Auditorías de TI realizadas para respaldar las auditorías de estados financieros

Una vez que el auditor ha adquirido una familiaridad general con los procedimientos contables y financieros del cliente,
Es necesario identificar áreas específicas de interés de auditoría. El auditor debe decidir qué aplicaciones
tendrá que examinarse a un nivel más detallado. Para aplicaciones utilizadas para respaldar negocios importantes
procesos, el auditor debe determinar su sofisticación y extensión de uso. Este preliminar
El estudio es lo suficientemente profundo como para que el auditor evalúe la complejidad y sofisticación del
solicitudes y determinar los procedimientos a seguir en la evaluación de sus controles internos.
Comprender las aplicaciones financieras y determinar si existen controles de TI para
asegurarlos de manera efectiva y la información generada representa un proceso significativo en lo que se refiere
a la auditoría general de los estados financieros. Los resultados de una auditoría de TI sobre aplicaciones financieras
Relación directa con las pruebas sustantivas realizadas por los auditores financieros. Pruebas sustantivas
implica procedimientos de auditoría necesarios para examinar y respaldar los estados financieros (p. ej.
reafirmar los saldos de las cuentas, examinar la documentación, volver a realizar los procedimientos, preguntar sobre
u observando una transacción, etc.). Estos procedimientos proporcionan la evidencia necesaria para respaldar la
afirmación de que los registros financieros de la organización son válidos, precisos y completos.
Los resultados o hallazgos de una auditoría de TI generalmente determinan la cantidad de pruebas sustantivas
que será realizado por auditores financieros. Si los resultados son efectivos (es decir, se determina que los controles de TI
estar en su lugar y funcionando correctamente), el trabajo del auditor financiero probablemente sería menor en
esa parte particular de la auditoría. Por otro lado, si no existen controles de TI implementados,
las aplicaciones financieras, o si los controles de TI existentes no funcionan de manera eficaz, la cantidad de
Las pruebas sustantivas realizadas por el auditor financiero serán mucho más elevadas. Esto puede tener un significado
implicaciones importantes para la auditoría, como el tiempo que lleva completar la auditoría, el aumento de los costos
cliente, etc. El resto de este capítulo se centra en las auditorías de TI realizadas para respaldar
auditorías de estados. El siguiente paso dentro del plan de auditoría es el desarrollo de un programa de auditoría.
Página 96
Programa de auditoría
Los departamentos de auditoría interna crean programas de auditoría anuales para obtener el acuerdo de la junta
en las áreas de auditoría, comunicar las áreas de auditoría con los departamentos funcionales y crear un proyecto /
plan de recursos para el año. El programa de auditoría debe estar vinculado a los objetivos comerciales actuales y
riesgos basados en su costo relativo en términos de pérdida potencial de fondo de comercio, pérdida de ingresos o incumplim
Cumplimiento de las leyes y reglamentos.
La creación del programa anual es el proceso de determinar el total de horas de auditoría disponibles, luego
asignando elementos del universo (áreas de auditoría) para llenar el tiempo disponible. Como se mencionó anteriormente, pa
Para optimizar el proceso de evaluación de riesgos, los elementos del universo de “alto riesgo” deben recibir la máxima prio
La creación del cronograma debe realizarse junto con el proceso anual de evaluación de riesgos;
Esto permitirá a los departamentos de auditoría interna dar cuenta de los cambios en las clasificaciones de riesgo y hacer
cualquier adición o supresión necesaria al universo de auditoría. Por supuesto, el programa de auditoría también
debe acordarse con el comité de auditoría como parte del proceso general de planificación de la auditoría. Una vez el
Se determinan las horas de auditoría disponibles, la gerencia de auditoría puede continuar preparando el plan de auditoría.
La planificación y la programación son tareas continuas como riesgos, prioridades, recursos disponibles y tiempo.
las líneas cambian. Cuando se produzcan estos cambios, es importante comunicarlos a la auditoría.
comité, junta y todos los demás departamentos funcionales afectados.
Auditoría de presupuesto y alcance

Idealmente, el presupuesto de auditoría debería crearse después de que se determina el programa de auditoría. Sin embargo,
las organizaciones tienen limitaciones presupuestarias y de recursos. Puede ser necesario un enfoque alternativo
al construir el cronograma de auditoría. Después de determinar las prioridades de auditoría, la gerencia de auditoría
determinar la cantidad de horas disponibles para decidir cuántas auditorías pueden completar en un año.
Para una auditoría de TI en particular, se enumeran las horas disponibles por área, personal, etc.
Trata un ejemplo de un presupuesto en una auditoría de TI.
El alcance de una auditoría define el área (s) (por ejemplo, aplicaciones financieras relevantes, bases de datos,
sistemas, redes, etc.) para ser revisados. Los nombres de las aplicaciones y bases de datos financieras
también debe describirse junto con su información de alojamiento (por ejemplo, ubicación del servidor, etc.). El alcance
debe identificar claramente el proceso comercial crítico respaldado por la aplicación financiera seleccionada
ción. Esta asociación suele justificar la relevancia de la aplicación y, por tanto, su inclusión
como parte de la auditoría. El alcance debe indicar además las áreas de control general, los objetivos de control,
y actividades de control que se someterían a revisión. El cuadro 3.5a, b muestra ejemplos de alcance para
aplicaciones y objetivos de control, respectivamente, en una auditoría de TI.
Equipo de auditoría, tareas y plazos

El plan de auditoría debe incluir una sección que enumere los miembros de la auditoría, sus títulos y cargos,
y las tareas generales que tendrán. Por ejemplo, una auditoría típica involucra a miembros del personal, personas mayores,
gerentes o gerentes senior, y un socio, director o director (PPD) que supervisará
toda la auditoría. A nivel del personal (generalmente los auditores con menos de 3 años de experiencia), la mayoría
del trabajo de campo se realiza, incluida la recopilación de documentación, la reunión con el personal y
creación de papeles de trabajo de auditoría , entre otros. Los auditores de alto nivel no solo supervisan el trabajo de
auditores del personal, pero guíelos en la realización del trabajo (por ejemplo, acompañe a los auditores del personal a reunir
usuarios, ayudar al personal a seleccionar qué información específica debe recopilarse, cómo documentar
tal información en los papeles de trabajo, etc.). A continuación están los gerentes o gerentes senior (senior
Página 97
Figura 3.4 Ejemplo de presupuesto para una auditoría de TI
nombre de empresa
Presupuesto de TI
Año fiscal 20XX
Profesional de Auditoría
Personal/ Total
Área de auditoría Mayor Gerente Compañero Horas
Planificación
Revise los documentos de trabajo de la 3,0 1.0 0.0 4.0

año, si aplica; preparar presupuesto de TI;
realizar reuniones de planificación; preparar
memorando de planificación; preparar inicial
solicitud de información y enviar a
personal de la empresa, etc.
Primer año. Reúna y documente un 3,0 1.0 0.0 4.0
comprensión de la organización y
su entorno de TI, incluida la forma en que
la organización utiliza un sistema informático
y qué aplicaciones tienen un impacto crítico
procesos comerciales / financieros, entre
otros.
Años subsecuentes. Revisión y actualización
la comprensión de la organización
y su entorno de TI obtenido de
el año anterior.
Llevar a cabo una reunión de planificación con 1.0 1.0 1.0 3,0
personal de la empresa.
Total parcial 7.0 3,0 1.0 11,0 11%
Trabajo de campo
Documentar / actualizar la comprensión de

el entorno de TI de la organización y
realizar pruebas de controles de TI (por
Área de Control General IT).
Operaciones de sistemas de información 16,0 0.0 0.0 16,0
Seguridad de información 17.0 0.0 0.0 17.0
Gestión de control de cambios 20,0 0.0 0.0 20,0
Total parcial 53,0 0.0 0.0 53,0 53%
( Continuacion )
Página 98
Figura 3.4 ( continuación ) Ejemplo de un presupuesto para una auditoría de TI
nombre de empresa
Presupuesto de TI
Año fiscal 20XX
Profesional de Auditoría
Personal/ Total
Área de auditoría Mayor Gerente Compañero Horas
Revisión, informes y conclusión
Revisar y documentar las acciones tomadas 2.0 0.0 0.0 2.0

por la Gerencia de la empresa para corregir
hallazgos de la auditoría de TI del año pasado /
deficiencias.
Documentar los hallazgos de la auditoría de TI / 3,0 0.0 0.0 3,0

deficiencias y oportunidades para
mejorar los controles existentes.
Evaluar y clasificar la auditoría de TI identificada 1.0 0.0 0.0 1.0

hallazgos / deficiencias.
Borrador de la carta de gestión de TI con una lista de todos 0.0 1.0 1.0 2.0
hallazgos / deficiencias de auditoría y
oportunidades para mejorar los
control S. Reenviar carta a TI
Gestión para revisión.
Llevar a cabo reuniones de estado, internamente o 1.0 0.0 0.0 1.0

con el personal de TI.
Revisar los documentos de trabajo que evidencian 0.0 9.0 4.0 13,0
Trabajo de auditoría de TI realizado.
Salir de la reunión con el personal de TI para 0.0 1.0 0.0 1.0

discutir la auditoría y los resultados.
Abordar y aclarar notas de revisión de 11,0 2.0 0.0 13,0

gestión de auditoría (Gerente y
Socio) y concluir la auditoría.
Total parcial 18,0 13,0 5,0 36,0 36%
Gran total 78,0 16,0 6.0 100,0 100%
Personal / Senior 78,0 78%
Gerente 16,0 dieciséis%
Compañero 6.0 6%
Página 99
Figura 3.5a Ejemplo de determinación del alcance para aplicaciones financieras
nombre de empresa
Aplicaciones financieras y su asociación con procesos comerciales
Año fiscal 20XX
Propósito: Identificar aplicaciones relevantes al mapearlas con sus procesos comerciales correspondientes. Una "X" en la tabla de la derecha identifica la emp
proceso apoyado por la aplicación. Por ejemplo, la aplicación SAP es utilizada por (o es compatible) con informes financieros , gastos , gestión de inventario
y Procesos comerciales de ingresos . Esta asociación generalmente justifica la relevancia de la solicitud y, por lo tanto, su inclusión como parte de la auditoría
Procesos comerc
Procesando
Medio ambiente
(Operando
Sistema Físico
Donde el Hosting
Solicitud Base de datos Ubicación--
Breve Esta instalado administración Solicitud Financiero Nómina y In
# Solicitud Descripción En) Software y base de datos Informe de gastos Personal Ingr
1 SAP Incluye el UNIX Oráculo Datos locales X X

general Centrar,
libro mayor, Segunda planta;
gastos, De la empresa
inventario Sede
administración, [ubicación]
e ingresos
contabilidad
módulos.
2 Infinium Gestiona el AS / 400 Oráculo Datos locales X

nómina de sueldos. Centrar,
Segunda planta;
De la empresa
Sede
[ubicación]
Página 100
Figura 3.5a ( continuación ) Ejemplo de alcance para aplicaciones financieras
nombre de empresa
Aplicaciones financieras y su asociación con procesos comerciales
Año fiscal 20XX
Propósito: Identificar aplicaciones relevantes al mapearlas con sus procesos comerciales correspondientes. Una "X" en la tabla de la derecha identifica la emp
proceso apoyado por la aplicación. Por ejemplo, la aplicación SAP es utilizada por (o es compatible) con informes financieros , gastos , gestión de inventario
y Procesos comerciales de ingresos . Esta asociación generalmente justifica la relevancia de la solicitud y, por lo tanto, su inclusión como parte de la auditoría
Procesos comerc
Procesando
Medio ambiente
(Operando
Sistema Físico
Donde el Hosting
Solicitud Base de datos Ubicación--
Breve Esta instalado administración Solicitud Financiero Nómina y In
# Solicitud Descripción En) Software y base de datos Informe de gastos Personal Ingr
3 APS / 2 Gestiona Ventanas Oráculo Datos locales

inversiones. Centrar,
Segunda planta;
De la empresa
Sede
[ubicación]
4 Timberline maneja mucho Ventanas Oráculo Datos locales

término y Centrar,
Activos fijos. Segunda planta;
De la empresa
Sede
[ubicación]
Página 101
Figura 3.5b Ejemplo de determinación del alcance de los objetivos generales de control por computadora y
Ocupaciones
nombre de empresa
Controles informáticos generales Objetivos y actividades seleccionados
Año fiscal 20XX
# Área de TI Objetivo de control Actividad de control
1 Información ISO 1.00 - Operaciones de TI ISO 1.01 - El procesamiento por lotes y / o en línea es
Sistemas apoyo adecuado definido, ejecutado oportunamente y monitoreado
Operaciones programación, ejecución, para completar con éxito.
seguimiento y continuidad ISO 1.02 - Excepciones identificadas en el lote
de sistemas, programas y y / o el procesamiento en línea es oportuno
procesos para asegurar la revisado y corregido para asegurar
completo, exacto y válido precisa, completa y autorizada
procesamiento y grabación de procesamiento de información financiera.
Transacciones financieras.
2 Información ISO 2.00 - El almacenamiento de ISO 2.02: las herramientas de copia de seguridad automatizadas
Sistemas la información financiera es se ha implementado para gestionar la retención
Operaciones adecuadamente gestionado, planes y horarios de datos.
precisa y completa. ISO 2.04 - Pruebas para la legibilidad de
las copias de seguridad se realizan periódicamente
base. Los resultados apoyan oportuna y
restauración exitosa de los datos respaldados.
3 Información ISO 3.00 - El acceso físico es ISO 3.02 - El acceso físico está autorizado,
Sistemas adecuadamente gestionado para monitoreado y restringido a individuos
Operaciones salvaguardar relevante que requieren tal acceso para realizar su
componentes de la TI deberes laborales. Entrada de no autorizados
infraestructura y la el personal está supervisado y registrado. los
integridad de las finanzas el registro se mantiene y se revisa periódicamente
información. por la gestión de TI.
4 Información ISEC 1.00 - Seguridad ISEC 1.02 - Políticas y procedimientos formales

Seguridad configuración de definir la información de la organización
aplicaciones, bases de datos, objetivos de seguridad y responsabilidades
redes, y operando de empleados con respecto a la protección
sistemas es adecuadamente y divulgación de recursos informativos.
logrado proteger contra La gerencia monitorea el cumplimiento de
cambios no autorizados a políticas y procedimientos de seguridad, y
programas y datos que pueden acuerdo con estos se evidencia por el
resultar en incompleto, firma de empleados.
inexacto o inválido ISEC 1.06: coherente con la información
procesamiento o grabación de políticas y procedimientos de seguridad, locales y
información financiera. los usuarios remotos deben autenticarse
a aplicaciones, bases de datos, redes y
sistemas operativos a través de contraseñas para
mejorar la seguridad informática.
( Continuacion )
Página 102
Figura 3.5b ( continuación ) Ejemplo de determinación del alcance para control general por computadora
Objetivos y actividades
nombre de empresa
Año fiscal 20XX
5 Información ISEC 2.00 - Seguridad adecuada ISEC 2.02: los propietarios del sistema autorizan al usuario
Seguridad se implementa para proteger cuentas y la naturaleza y alcance de
contra no autorizado sus privilegios de acceso.
acceso y modificaciones de ISEC 2.04 - Usuarios que han cambiado de roles o
sistemas e información, tareas dentro de la organización, o que tienen
que puede resultar en la han sido transferidos o rescindidos son
procesamiento o grabación de Inmediatamente informado a la seguridad
incompleto, inexacto o departamento de acceso a la cuenta de usuario
financiero inválido revisión para reflejar lo nuevo y / o
información. estado revisado.
ISEC 2.05 - Transmisión de sensibles
la información está encriptada de acuerdo con
políticas y procedimientos de seguridad para proteger
su confidencialidad.
6 Cambio CCM 1.00 - Cambios CCM 1.03 - Documentación relacionada con la

Controlar implementado en la implementación del cambio es adecuada y
administración aplicaciones, bases de datos, completar.
redes, y operando CCM 1.05 - Documentación relacionada con la
sistemas (en conjunto se ha lanzado la implementación del cambio
referido como "sistema y comunicado a los usuarios del sistema.
cambios ”) se evalúan para
riesgo, autorizado y
completamente documentado para
asegúrese de que los resultados deseados sean
adecuado.
7 Cambio CCM 2.00 - Cambios CCM 2.01: se prueban los cambios del sistema
Controlar implementado en antes de la implementación en el
administración aplicaciones, bases de datos, entorno de producción consistente con
redes, y operando planes de prueba y casos.
sistemas (en conjunto referidos CCM 2.02 - Planes de prueba y casos que involucran
como "cambios del sistema") son datos de prueba completos y representativos
debidamente probado. Pruebas (en lugar de datos de producción) están aprobados
son realizadas por un grupo por propietarios de aplicaciones y desarrollo
que no sea el grupo administración.
responsable del sistema
(por ejemplo, sistemas operativos
los cambios se implementan
por alguien que no sea el
programador de sistemas, etc.).
( Continuacion )
Página 103
Figura 3.5b ( continuación ) Ejemplo de determinación del alcance para control general por computadora
Objetivos y actividades
nombre de empresa
Año fiscal 20XX
8 Cambio CCM 3.00 - Cambios CCM 3.01 - Problemas y errores

Controlar implementado en encontrado durante la prueba del sistema
administración aplicaciones, bases de datos, los cambios se identifican, corrigen, vuelven a probar,
redes, y operando seguimiento para corrección, y
sistemas (en conjunto documentado.
referido como "sistema
cambios ") son los adecuados
logrado reducir
interrupciones, no autorizado
alteraciones y errores
que impactan la precisión,
integridad y validez
procesamiento y grabación
de información financiera.
9 Cambio CCM 4.00 - Cambios CCM 4.04: se realiza una revisión general
Controlar implementado en por la administración después de que los cambios en el sistema
administración aplicaciones, bases de datos, sido implementado en vivo o
redes, y operando entorno de producción para determinar
sistemas (en conjunto si los objetivos de implementación
referido como "sistema se cumplieron los cambios del sistema.
cambios ") son formalmente
aprobado para apoyar
precisa, completa y
procesamiento válido y
registro de finanzas
información.
los gerentes suelen participar como parte de grandes auditorías) que supervisan el trabajo de auditoría preparado por
el personal y revisado por el senior. Los gerentes realizan revisiones detalladas de los papeles de trabajo y
asegurarse de que se hayan alcanzado los objetivos de la auditoría. Los gerentes se reúnen frecuentemente con clientes de au
proporcionarles el estado de la auditoría, los hallazgos preliminares identificados, las horas incurridas y las que quedan por t
etc. Los gerentes también proporcionan el estado frecuente del trabajo de auditoría al PPD asignado, al que
informar directamente. Por último, el PPD realiza una revisión de alto nivel del trabajo (según lo dispuesto por la gerencia
ers), enfocándose en áreas de alto riesgo, controles implementados que no están diseñados ni operando adecuadamente
efectivamente, los hallazgos identificados y su impacto en la auditoría general, etc. Los PPD tienden a depender de la
revisiones detalladas realizadas por gerentes o altos directivos, y también garantizar los objetivos generales
de la auditoría.
Los plazos son un componente crítico de un plan de auditoría. Deben revisarse y acordarse con
la organización del cliente desde el inicio de la auditoría para que cumplan con los requisitos establecidos
emitidos por terceros (por ejemplo, bancos, instituciones financieras, etc.) y reguladores (por ejemplo, gobierno,
Página 104
organizaciones privadas, etc.). Los plazos deben estar bien pensados para tener en cuenta la información
mación y recursos que deben estar disponibles para realizar el trabajo de auditoría dentro de los
requisitos.
Un memorando de planificación de auditoría ("memorando de planificación") es parte de los papeles de trabajo del audi
documenta las secciones recién descritas. El memorando de planificación lo prepara normalmente la auditoría.
compromiso senior, y revisado por el gerente antes de enviarlo al PPD para su aprobación.
El Apéndice 1 muestra el formato de un memorando de planificación de TI típico, incluidos los procedimientos que pueden
ser realizado por un auditor de TI en relación con un trabajo de auditoría. El memorando de planificación puede
estar adaptados a los hechos y circunstancias específicos del trabajo de auditoría. Esto incluye remov
ing secciones que no son aplicables. El memo en el Apéndice 1 incluye algunas palabras en cursiva
que está encerrado entre corchetes o paréntesis. Este formato se utiliza para indicar información
para ser reemplazado según corresponda, o que oriente la finalización del memo.
Proceso de auditoría
Declaración sobre normas de auditoría (SAS No. 1) tiene el efecto de exigir un proceso uniforme
enfoque orientado a los trabajos de auditoría. El enfoque descrito es una verdadera técnica de proceso. Ese
Es decir, las auditorías siguen una serie de pasos lógicos y ordenados, cada uno diseñado para lograr resultados finales espec
Este también es el caso de una auditoría de TI. La diferencia en una auditoría de TI es el enfoque especializado de la
el trabajo de auditoría y las habilidades necesarias para comprender la tecnología y el entorno de control de TI. los
Las fases de las actividades de auditoría suelen superponerse e implican alguna reevaluación y seguimiento de los
ceduras realizadas antes. Las fases comunes de un trabajo de auditoría se muestran en el Cuadro 3.6.
Las dos primeras fases, Evaluación de riesgos y Plan de auditoría , se han explicado anteriormente. Los siguientes son
explicaciones de las fases restantes relacionadas con una auditoría de TI.
Revisión preliminar
En esta fase, el auditor debe obtener y revisar la información a nivel de resumen y evaluarla.
en relación con los objetivos de la auditoría. El propósito de la fase de revisión preliminar de una auditoría de TI
El compromiso es obtener una comprensión del entorno de TI, incluidos los controles establecidos.
1. Evaluación de riesgos
8. Comunicación 2. Plan de auditoría
7. Documento 3. Preliminar
resultados revisión
6. Sustantivo 4. Auditoría de diseño

pruebas procedimientos
5. Controles de prueba
Figura 3.6 Fases de una auditoría.

Página 105
que son esenciales para cumplir con los objetivos generales de auditoría. El auditor de TI realiza este preliminar
Revisión a nivel general, sin examinar los detalles de las aplicaciones individuales y los procesos.
involucrado. En cambio, el auditor de TI entrevista al personal clave para determinar las políticas y prácticas, y
prepara información de auditoría complementaria según sea necesario. La información de la revisión preliminar sirve como
base para sustentar la información incluida en el plan de auditoría de TI.
Información general sobre el entorno de TI

Como se discutió anteriormente, TI se define como el hardware, software, comunicación y otros
instalaciones utilizadas para ingresar, almacenar, procesar, transmitir y generar datos en cualquier forma. La cosa
medio ambiente se refiere a las políticas, procedimientos y prácticas implementadas por las organizaciones para
programar, probar, entregar, monitorear, controlar y dar soporte a su infraestructura de TI (por ejemplo, hardware, software
mercancías, redes, etc.). El entorno de TI también incluye las aplicaciones y programas utilizados por
organizaciones para respaldar operaciones comerciales críticas (es decir, operaciones financieras) y lograr
estrategias de ness.
El auditor de TI comienza el proceso de examen familiarizándose, en general, con el
empresa, su línea de negocio y el entorno de TI, incluidos sus sistemas de aplicaciones financieras.
Por lo general, un auditor de TI recorrería las instalaciones de la empresa cliente y observaría los negocios generales
operaciones que inciden tanto en el servicio al cliente como en funciones estrictamente financieras.
Dada esta familiaridad, el siguiente nivel de recopilación de datos generales incluiría la preparación
de organigramas, en particular los de las funciones de contabilidad e informática. Si organizacional
Los gráficos no están disponibles, el auditor de TI debe desarrollarlos. Una vez dibujados, los gráficos deben
revisado y verificado con el personal apropiado (es decir, ejecutivos clave en contabilidad y TI
áreas) para asegurar un acuerdo de que representan la estructura real de la organización. Durante estos
entrevistas, el auditor de TI también obtendría copias del plan de cuentas de la empresa y un
manual de normas contables, si está disponible.
Los auditores de TI deben obtener un conocimiento profundo del entorno de TI, particularmente cómo
La organización responde a los riesgos que surgen de TI, y si los controles de TI implementados se han
adecuadamente diseñados y funcionan de manera eficaz para abordar esos riesgos. Desde un punto de vista financiero,
El conocimiento sobre el entorno de TI es crucial para los auditores de TI a fin de comprender cómo
Las transacciones comerciales se inician, autorizan, registran, procesan y reportan en el
declaraciones.
Para los sistemas de aplicación que la organización utiliza computadoras para procesar importantes
datos, el auditor de TI recopilaría una serie de elementos específicos de evidencia, tales como:
◾ Políticas y procedimientos que implementa la organización y la infraestructura de TI y

software de aplicación que utiliza para respaldar las operaciones comerciales y lograr negocios
estrategias.
◾ Las narrativas o los diagramas de flujo de descripción general de las aplicaciones financieras, incluidos los nombres de
y modelo, sistemas operativos de apoyo, bases de datos y ubicaciones físicas, entre otros.
◾ Ya sea que las aplicaciones financieras se desarrollen internamente, se compren con poca o ninguna
personalización, comprado con personalización significativa o propiedad proporcionada por un servicio
organización.
◾ Si las organizaciones de servicios albergan aplicaciones financieras y, de ser así, ¿cuáles son estas aplicaciones?
ciones y qué servicios relevantes realizan.
◾ Controles implementados que apoyan el área de operaciones de sistemas de información, como los
portando programación de trabajos, datos y restauración, copias de seguridad y almacenamiento externo.
Página 106
◾ Controles implementados que respaldan el área de seguridad de la información, como los que respaldan
técnicas de autenticación (es decir, contraseñas), nuevos procedimientos de acceso o terminación, uso de
firewalls y cómo se configuran, seguridad física, etc.
◾ Controles implementados que apoyan el área de gestión de control de cambios, como los
portando la implementación de cambios en aplicaciones, sistemas operativos y bases de datos;
probar si el acceso de los programadores es adecuado; etc.
Los métodos aplicados en la recopilación de estos datos incluyen la revisión de los sistemas informáticos de información y
prácticas, procedimientos, documentos, narrativas, diagramas de flujo y diseños de registros de la interfaz humana. Otro
Los procedimientos de auditoría implementados para recopilar datos incluyen: observar, entrevistar, inspeccionar
documentación y diagramas de flujo, entre otros. Las técnicas de inspección física se utilizan tanto para
recopilar datos y validar documentos existentes o representaciones realizadas durante las entrevistas. por
Por ejemplo, una sola visita a la computadora / centro de datos puede proporcionar tanto la recopilación como la validación
oportunidades para determinar configuraciones de equipos, procedimientos de biblioteca, procedimientos operativos,
controles de seguridad física, controles ambientales existentes y otros procedimientos de control de datos.
Muchos de estos procedimientos son sustancialmente los mismos independientemente de si la contabilidad
el sistema está informatizado o no. Diferencias asociadas a la auditoría de sistemas informáticos
centrarse en los cambios en los controles, la documentación, las técnicas de auditoría y las calificaciones técnicas
requerido por los miembros del personal de auditoría. El Apéndice 2 muestra un ejemplo de los tipos de preguntas y
información que debe documentarse cuando se comprenda un entorno de TI.
Procedimientos de auditoría de diseño

En esta fase, el auditor de TI debe preparar un programa de auditoría para las áreas que se auditan, seleccionar control
objetivos aplicables a cada área, e identificar procedimientos o actividades para evaluar dichos objetivos. Un
programa de auditoría difiere de un cuestionario de control interno (ICQ) en que un ICQ implica preguntas
ciones para evaluar el diseño del sistema de control interno. En particular, los ICQ comprueban si los controles
se implementan para detectar, prevenir o corregir una incorrección material . Los controles que no están en su lugar
representan una desviación o deficiencia en la estructura de control interno. Un programa de auditoría, por otro
Por otro lado, contiene procedimientos específicos para probar las respuestas recibidas de las preguntas formuladas, sub-
demostrando que los controles identificados están en su lugar y funcionan según lo esperado por la gerencia.
Un programa de auditoría es un plan formal para revisar y probar cada área importante de auditoría.
revelado durante la recopilación de hechos. El auditor debe seleccionar áreas temáticas para las pruebas que tengan un signo
impacto significativo en el control de la aplicación y aquellos que se encuentran dentro del alcance definido por el
objetivos de la auditoría. Las áreas de auditoría de TI son muy específicas para el tipo de auditoría. Para TI, COBIT es un ex
prestó el punto de partida, ya que enumera los riesgos, objetivos y controles clave por área de auditoría de TI. Esta informac
luego tiene que adaptarse a los objetivos, procesos y tecnología particulares de la organización.
El Apéndice 3 ilustra ejemplos de programas de auditoría de TI para las áreas generales de control de TI.
Identificación de aplicaciones financieras

Con la ayuda de la dirección, el auditor de TI debe decidir qué sistemas de aplicación deberán
ser examinado a un nivel más detallado (es decir, alcance). Como base para la preparación del plan de auditoría, el
El auditor de TI también debe determinar, en general, cuánto tiempo se requerirá, qué tipo de personas
y se necesitarán habilidades para realizar el examen; y, aproximadamente, cuál será el horario.
La identificación de aplicaciones financieras se puede lograr con el auditor ganando
familiaridad con los procedimientos y procesos contables de la organización. La importancia de
Página 107
La determinación de las aplicaciones financieras significativas debe derivarse de un análisis preliminar.

La evaluación de la sofisticación de la aplicación, su complejidad, el proceso de negocio que
el apoyo y el alcance del uso son factores que entran en juego al decidir si seleccionar tales aplicaciones
catión y cómo se podría evaluar. Como se indicó anteriormente, la fase de revisión preliminar es un
paso en el proceso de auditoría que examina los sistemas financieros de una organización y proporciona al auditor
con una base para seleccionar áreas de auditoría para un análisis y una evaluación más detallados, ya sea que sean
manual o informatizado.
Los auditores involucrados en la revisión de las solicitudes financieras deben centrar sus preocupaciones en la solicitud.
aspectos de control del catión. Esto requiere su participación desde el momento en que se inicia una transacción.
hasta que se registre en el libro mayor de la organización. Específicamente, los auditores deben asegurarse de que
se toman disposiciones para:
◾ Una pista de auditoría adecuada para que las transacciones se puedan rastrear hacia adelante y hacia atrás
la aplicación financiera
◾ La documentación y la existencia de controles sobre la contabilidad de todos los datos (por ejemplo, transacciones
ciones, etc.) ingresados en la aplicación y controles para garantizar la integridad de esas transacciones
ciones en todo el segmento informatizado de la aplicación
◾ Manejo de excepciones y rechazos de la aplicación financiera
◾ Pruebas unitarias e integradas, con controles establecidos para determinar si las aplicaciones
realizar como se indica
◾ Controla los cambios en la aplicación para determinar si la autorización adecuada
sido dado y documentado
◾ Procedimientos de autorización para anulaciones del sistema de solicitud y documentación de
esos procesos
◾ Determinar si se cumplen las políticas y procedimientos de la organización y el gobierno
en la implementación del sistema
◾ Capacitar al personal usuario en el funcionamiento de la aplicación financiera
◾ Desarrollar criterios de evaluación detallados para que sea posible determinar si la implementación
La aplicación mentada ha cumplido con especificaciones predeterminadas.
◾ Controles adecuados entre sistemas de aplicaciones interconectados
◾ Procedimientos de seguridad adecuados para proteger los datos del usuario
◾ Procedimientos de respaldo y recuperación para el funcionamiento de la aplicación y garantía de
continuidad del negocio
◾ Asegurar que la tecnología proporcionada por diferentes proveedores (es decir, plataformas operativas)
patible y controlado
◾ Bases de datos adecuadamente diseñadas y controladas para asegurar que las definiciones comunes de datos sean
utilizado en toda la organización, la redundancia se elimina o controla, y los datos existentes
en varias bases de datos se actualiza al mismo tiempo
Esta lista afirma que el auditor de TI se preocupa principalmente por los controles adecuados para salvaguardar la
activos de la organización.
Controles de prueba
El auditor de TI ejecuta varios procedimientos para probar controles, procesos y aparentes
exposiciones. Estos procedimientos de auditoría pueden incluir el examen de evidencia documental, así como
como realizar entrevistas de corroboración, inspecciones y observaciones personales.
Página 108
La evidencia documental puede consistir en una variedad de formas de documentación sobre la solicitud
sistema en revisión. Los ejemplos incluyen notas de reuniones sobre sistema temático, programador
notas, documentación de sistemas, capturas de pantalla, manuales de usuario y documentación de control de cambios
de cualquier cambio de sistema u operación desde el inicio, y una copia del contrato si terceros
involucrado. El examen de dicha evidencia documental puede requerir que el auditor de TI haga preguntas
el usuario, desarrollador y gerentes para ayudarlo a establecer los criterios de prueba apropiados para ser
usado. También ayuda a identificar la aplicación y los procesos críticos que se van a probar.
Las entrevistas de corroboración también son parte del proceso de prueba y pueden incluir procedimientos como:
◾ Hacer la misma pregunta a diferentes empleados y comparar sus respuestas

◾ Hacer la misma pregunta de diferentes maneras en diferentes momentos
◾ Comparar respuestas con documentación de respaldo, documentos de trabajo, programas, exámenes u otros
resultados verificables
◾ Comparar respuestas a observaciones y resultados reales del sistema
Un ejemplo implicaría entrevistar a un programador para una aplicación bajo revisión. El PRO-
grammer indica que la aplicación ha sufrido cambios recientes que no se reflejan en la
documentación. Es muy importante identificar cuáles fueron esos cambios si esas áreas del
la aplicación debía seleccionarse para las pruebas de control.
Para la inspección de la documentación, el auditor de TI puede obtener la configuración lógica (es decir, contraseñas)
actualmente configurado en la red, el sistema operativo y la aplicación financiera de la organización
niveles. Es de particular importancia obtener y evaluar la configuración lógica de la red.
ya que este es el primer nivel de autenticación antes de que los usuarios puedan acceder a las aplicaciones financieras.
La configuración recibida se compara con la política de contraseñas de la organización para determinar
si cumplen o no con dichas políticas. En ausencia de una política de contraseñas, el
Los ajustes lógicos de la organización configurados se comparan con los estándares de la industria o las mejores prácticas.
tices. La documentación que respalda las configuraciones anteriores generalmente se obtiene primero a través de entrevistas
personal de seguridad de la información.
Otro procedimiento de auditoría común para probar y validar información sería observar
procedimientos en curso. En el ejemplo anterior, el auditor de TI observaría la configuración de ajustes
ured en la aplicación financiera y solicite al personal de la organización que imprima una captura de pantalla para
documentación en los papeles de trabajo de auditoría. La figura 3.7a muestra un ejemplo de documentos comunes
Mentación obtenida que respalda los ajustes de contraseña configurados. En este caso, configuraciones como
historial de contraseñas forzadas, antigüedad mínima (o máxima) de la contraseña, longitud mínima de la contraseña,
complejidad de la contraseña, duración y umbral del bloqueo de la cuenta, y si las contraseñas tienen
almacenados con cifrado reversible son algunos de los ajustes que normalmente se recopilan. Un
El documento de trabajo del auditor de TI que documente las pruebas de algunas de estas configuraciones se vería como el
en la figura 3.7b. Observe en la tabla las configuraciones de contraseña reales configuradas documentadas en el
red (o el primer nivel de autenticación), sistema operativo y niveles de aplicaciones financieras. también
notar notas y marcas de verificación (explicaciones) sobre la información contenida y, lo más importante,
la evaluación de si la configuración de la contraseña del cliente cumple con la empresa existente
política o estándares y mejores prácticas de la industria. Cuando la configuración no cumple con la política
o estándares de la industria o mejores prácticas, las excepciones de auditoría (hallazgos) se escriben y enumeran en un
papel de trabajo separado. Este documento de trabajo eventualmente ayudará a redactar los hallazgos /
sección de deficiencias de la Carta de gestión . Un segundo ejemplo de observación como procedimiento de prueba
involucraría a un auditor de TI examinando un ejercicio de recuperación de desastres. Aquí, el auditor de TI podría
determinar si el personal siguió los procedimientos y procesos adecuados. A través de personal
Página 109
Figura 3.7a Ejemplo de evidencia que respalda la configuración de seguridad lógica (contraseña) actualmente
implementado.
observaciones, el auditor puede evaluar y determinar si el personal está siguiendo los

cedimientos y planes, y está adecuadamente preparado para el desastre simulado.
Pruebas sustantivas
Cuando se determina que los controles no son efectivos, se pueden requerir pruebas sustantivas para determinar
si existe un problema material con la información financiera resultante. En una auditoría de TI,
Las pruebas tivas se utilizan para determinar la precisión y la integridad de la información que se genera.
por un proceso o aplicación. Contrario a las pruebas de cumplimiento donde el objetivo del auditor es confirmar
si la organización se está adhiriendo a las políticas, procedimientos, reglas y regulaciones aplicables. Un
ejemplo de un procedimiento de prueba de cumplimiento sería verificar que un cambio o actualización en un
La aplicación fue probada, aprobada y documentada adecuadamente antes de su implementación.
Página 110
Figura 3.7b Ejemplo de soporte de una prueba de configuración de seguridad lógica
Configuración lógica
Red /
Sistema / Hacer cumplir Mínimo Mínimo
Financiero Contraseña Contraseña Contraseña Contraseña Cuenta
# Solicitud Historia Años Longitud Complejidad Bloqueo
Según la política de la empresa 5 contraseñas 90 dias 6 caracteres Habilitado 3 inválido

[ documento de trabajo recordado iniciar sesión
(w / p) ## ] {1} intentos
Pruebas reales realizadas
Área local 0 contraseñas 0 días 4 caracteres Discapacitado 0 inválido

Red recordado {un} {un} {un} iniciar sesión
(LAN) / {un} intentos
Ventanas {un}
1 Financiero {segundo} {segundo} {segundo} {segundo} {segundo}

Aplicación X
2 Financiero Opción no 90 dias 6 caracteres Habilitado 3 inválido

Aplicación Y disponible-- {C} {C} {C} iniciar sesión
Solicitud intentos
limitación {C}
{re}
Nota: Los valores de contraseña anteriores se obtuvieron mediante observación y con la ayuda
de [ nombre del administrador de seguridad de la información ].
Marcas de graduación (explicaciones):
{1} –– Configuración de la contraseña obtenida de la política de la empresa. Copia de la política de la empresa que respalda
estas configuraciones están documentadas en w / p [##].
{a} –– El historial de ejecución de contraseñas, la antigüedad mínima de la contraseña, la longitud mínima de la contraseña,
Las configuraciones de Complejidad de contraseña y Bloqueo de cuenta no están configuradas de acuerdo con
política de la empresa y, por lo tanto, no promueven un nivel aceptable de seguridad. El valor
configurado para la complejidad de la contraseña también se ha establecido en "Desactivado". Complejidad de la contraseña
Los requisitos establecen parámetros mínimos de contraseña que no se comprometen fácilmente
los usuarios deben seguir para establecer sus contraseñas, particularmente a nivel de LAN / Windows,
que sirve como la primera capa de autenticación. Se señalaron excepciones. Consulte w / p [##], donde
estas excepciones se han enumerado.
{b} –– La configuración de seguridad de la contraseña se controla a través del sistema operativo Windows.
Por lo tanto, la configuración de la contraseña de LAN / Windows cubre esta aplicación.
ción. Consulte la fila LAN / Windows anterior.
{c} –– Configuración de seguridad de la contraseña, como Antigüedad mínima de la contraseña, Longitud mínima de la contraseña,
La complejidad de la contraseña y el bloqueo de la cuenta se han configurado de acuerdo con la
política de la empresa, promoviendo un adecuado nivel de seguridad. No se observaron excepciones.
{d} –– Las limitaciones de la funcionalidad de la aplicación no permiten la aplicación del historial de contraseñas.
Se señalaron excepciones. Consulte w / p [##], donde se ha incluido esta excepción.
Página 111
Las pruebas de auditoría sustantiva están diseñadas y realizadas para verificar la precisión funcional, la eficiencia,
y control del sujeto de la auditoría. Durante la auditoría de una aplicación financiera, por ejemplo, la TI
El auditor construiría y procesaría datos de prueba para verificar los pasos de procesamiento de dicha aplicación.
Auditoría a través de la computadora es un término que involucra pasos además de los mencionados
previamente. Los programas se ejecutan en la computadora para probar y autenticar programas de aplicación
que se ejecutan en proceso normal. Por lo general, el equipo de auditoría financiera seleccionará uno de los muchos
Paquetes de software de auditoría generalizados como SAS, SPSS, técnicas de auditoría asistidas por computadora
(CAAT) o CA-Easytrieve (T) y determine qué cambios son necesarios para ejecutar el software
en la instalación. Los auditores financieros utilizan este software específico para realizar muestreos, extracción de datos,
informes de excepciones, resúmenes y totales de pie, y otras tareas. También usan paquetes como
como Microsoft Access, Excel, IDEA o ACL debido a sus análisis e informes en profundidad
Capacidades
Los CAAT, por ejemplo, utilizan especificaciones proporcionadas por el auditor para generar un programa que
funciones de auditoría, como la evaluación de controles de aplicación, la selección y el análisis
datos para pruebas de auditoría sustantivas, etc. En esencia, los CAAT automatizan y simplifican el proceso de auditoría,
y es por eso que los equipos de auditoría (externos e internos) los utilizan cada vez más. De hecho, muchas organizaciones
nizaciones tienen software de auditoría generalizada ya instalado para que sus auditores internos permitan
ellos para recopilar información y realizar las pruebas de auditoría planificadas. La selección adecuada y
El uso eficaz de estas herramientas de auditoría es esencial no solo para realizar las pruebas de auditoría adecuadas, sino tam
para documentar los resultados.
Resultados del documento

La siguiente fase de una auditoría implica documentar los resultados del trabajo realizado, así como informar
sobre los hallazgos. Los resultados de la auditoría deben incluir una descripción de los hallazgos, conclusiones y
recomendaciones.
Resultados de la auditoría
Los términos hallazgo, excepción, deficiencia, desviación, problema y problema son básicamente sinónimos
en el mundo de la auditoría, y significa que el auditor identificó una situación en la que los controles, procedimientos o
las ciencias pueden mejorarse. Los hallazgos identifican y describen información inexacta, ineficiente o inadecuada
sujetos de auditoría controlados. Un ejemplo de un hallazgo de auditoría de TI sería un cambio implementado en
una solicitud financiera que no incluía la debida autorización de gestión. Otro ejemplo
incluiría que el auditor de TI descubra que el manual de procedimientos de la organización no
requieren el permiso de la administración antes de implementar cambios en las aplicaciones.
Los hallazgos de la auditoría deben documentarse individualmente y deben incluir al menos lo siguiente:
◾ Nombre del entorno de TI (sistema operativo que aloja las aplicaciones financieras relevantes)
evaluado
◾ Área de TI afectada (operaciones de SI, seguridad de la información, gestión de control de cambios)
◾ Referencia de prueba de papel de trabajo donde se identificó el hallazgo
◾ Objetivo (s) de control general y actividad (es) que fallaron
◾ Breve descripción del hallazgo
◾ ¿Dónde se comunica formalmente el hallazgo a la gerencia (esto debe hacer referencia al
Carta de gestión dentro del informe de auditoría )
Página 112
◾ La clasificación individual del hallazgo según la norma de auditoría AU 325, Comunicaciones

Acerca de las deficiencias de control en una auditoría de estados financieros , ya sea como una deficiencia,
deficiencia de canto, o una debilidad material *
◾ Evaluación del hallazgo, específicamente si se identificó a nivel de diseño (es decir, no
no existe un control general) o en el nivel operativo (es decir, el control general estaba en su lugar,
pero no probó de manera efectiva)
◾ Si el hallazgo representa o no un riesgo generalizado o de nivel de entidad
◾ Si el hallazgo puede mitigarse mediante otros controles generales compensatorios y, de ser así,
incluir una referencia a dónde se han probado estos controles con éxito
Se puede utilizar un formulario de hallazgos de auditoría (por ejemplo, Formulario de hallazgos de controles informáticos ge
revisar los problemas de control identificados con el gerente de TI responsable para acordar la corrección
acción tiva. Esta información se puede utilizar para preparar la Carta de gestión formal que
acompañar el Informe de Auditoría y los seguimientos de las acciones correctivas. Tomar medidas correctivas podría
resultar en una mayor productividad; la disuasión del fraude; o la prevención de pérdidas monetarias,
lesiones sonales o daños ambientales. La figura 3.8 muestra un ejemplo de una hoja de trabajo que puede
se utiliza para resumir los hallazgos individuales identificados durante una auditoría de TI.
Conclusiones y Recomendaciones
Las conclusiones son opiniones del auditor, basadas en evidencia documentada, que determinan si
un área temática de la auditoría cumple con el objetivo de la auditoría. Todas las conclusiones deben basarse en datos fáctico
obtenido y documentado por el auditor como resultado de la actividad de auditoría. El grado en que el
las conclusiones están respaldadas por la evidencia es una función de la cantidad de evidencia asegurada por
el auditor. Las conclusiones están documentadas en los papeles de trabajo de auditoría y deben respaldar la
Procedimientos de auditoría realizados. Los papeles de trabajo son la colección formal de escritos pertinentes, documentos
mentos, diagramas de flujo, correspondencia, resultados de observaciones, planes y resultados de pruebas, la auditoría
plan, actas de reuniones, registros computarizados, archivos de datos o resultados de aplicaciones y evaluaciones
que documenten la actividad del auditor durante todo el período de auditoría. Un completo, bien organizado, transversal
un conjunto de documentos de trabajo referenciados y legibles es esencial para respaldar los hallazgos, las conclusiones y
recomendaciones como se indica en el Informe de auditoría. Normalmente, se archiva una copia del informe de auditoría fin
en los papeles de trabajo.
Las recomendaciones son declaraciones formales que describen un curso de acción que debe implementarse
la administración de la empresa para restaurar o proporcionar precisión, eficiencia o
control de los sujetos de auditoría. El auditor debe proporcionar una recomendación para cada hallazgo de auditoría.
para que el informe sea útil para la dirección.
Comunicación
El valor de una auditoría depende, en gran parte, de la eficiencia y eficacia de sus resultados.
Comunicado. Al concluir las pruebas de auditoría, es mejor discutir los hallazgos identificados con
Gestión de TI para obtener su consentimiento y comenzar cualquier acción correctiva necesaria. Recomendaciones,
riesgos como resultado de esos hallazgos, y las recomendaciones de auditoría generalmente se documentan en el
Carta de gestión (en una sección separada del Informe de auditoría). Consulte el Anexo 3.9 para ver un ejemplo.
del formato de una carta de gestión de una auditoría de TI.
* http://pcaobus.org/Standards/Auditing/Pages/AU325.aspx.
Página 113
Figura 3.8 Ejemplo de documentación de respaldo de los hallazgos generales del control por computadora identific
nombre de empresa
Hallazgos de GCC
Año fiscal 20XX
No./IT
Medio ambiente: TI Breve descripción del hallazgo Clasificación del
Área / W / P Comunicado a Deficiencia (
Referencia # Gestión en En funcionam
Donde encontrar Control fallido [Número de referencia de W / P de TI Deficiencia o
Fue identificado Objetivo de control Actividad Carta de la dirección] Debi
1 / Windows–– ISEC 2.00 - ISEC 2.04 - Usuarios Notamos que la notificación Deficiencia operat
Información Adecuado quien tiene para la terminación de Human La deficiencia no
Seguridad / W / P la seguridad es roles cambiados o Recursos (HR) para dos usuarios representar un ma
Referencia # implementado para tareas dentro del cuentas seleccionadas para la prueba debilidad (es deci
proteger contra organización, o no fue recibido por TI prevenir o detecta
no autorizado eso ha sido personal dentro de siete incorrecciones m
acceso y transferido, o días laborales. También notamos Estados financier
modificaciones de terminados son que la cuenta de usuario de uno la deficiencia tam
sistemas y inmediatamente empleado despedido suficiente para m
información, informado a la permaneció activo en el de los acusados d
que puede resultar seguridad [ nombre de la aplicación financiera ]. gobernanza (es de
en el procesamiento departamento para Además, cinco de cada seis deficiencia). Sim
o grabación de cuenta de usuario empleados despedidos funcionamiento d
incompleto, revisión de acceso probado, notificación del el control no perm
inexacto, o a fin de que el despido del empleado fue dirección o emple
financiero inválido reflejar lo nuevo no enviado inmediatamente o en el curso norma
información. y / o revisado dentro de siete días hábiles realizando su asig
estado. del empleado funciones, para p
supervisor o RR.HH. a TI y / o corregir erro
personal. en forma oportun
Página 114
Figura 3.8 ( continuación ) Ejemplo de documentación de respaldo de los hallazgos generales del control por compu
nombre de empresa
Hallazgos de GCC
Año fiscal 20XX
No./IT
2 / UNIX–– ISEC 2.00 - ISEC 2.03 - Usuario No notamos acceso formal Lo mismo que arri
Información Adecuado acceso a la cuenta las revisiones fueron realizadas por
Seguridad / W / P la seguridad es los privilegios son Personal de TI y / o
Referencia # implementado para periódicamente propietarios de empresas / aplicaciones
proteger contra revisado por para el financiero relevante
no autorizado sistemas y aplicaciones en el alcance.
acceso y solicitud
modificaciones de propietarios a
sistemas y determinar
información, si son
resultando en el razonable y /
procesamiento o o permanecer
grabación de apropiado.
incompleto,
inexacto, o
inválido
información.
Página 115
Figura 3.8 ( continuación ) Ejemplo de documentación de respaldo de los hallazgos generales de control por compu
nombre de empresa
Hallazgos de GCC
Año fiscal 20XX
No./IT
3 / Linux–– ISEC 1.00 - Seguridad ISEC 1.07 - Aunque el acceso a Lo mismo que arri
Información configuración de Las contraseñas deben [ Solicitud financiera 1, 2,
Seguridad / W / P aplicaciones, promover etc. ] requiere que los usuarios primero
Referencia # bases de datos, niveles aceptables autenticarse en la red
redes, y de seguridad nivel, hubo aplicación-
operando (consistente con nivel de configuración de seguridad lógica
sistemas es políticas y / o identificados que no estaban en
adecuadamente mejor industria de acuerdo con el
logró prácticas) por contraseña local de la empresa
proteger contra hacer cumplir política, y por lo tanto puede
no autorizado confidencialidad no promover óptimo
cambios a y un fuerte seguridad.
programas y contraseña
datos que pueden formato.
resulta en
incompleto,
inexacto, o
inválido
procesamiento o
grabación de
financiero
información.
Página 116
Figura 3.9 Ejemplo de una carta de administración de una auditoría de TI
nombre de empresa
Carta de gestión: auditoría de TI
Año terminado el 31 de diciembre de 20XX
Los hallazgos a continuación se han priorizado en orden de importancia y se han discutido con [ nombre
y cargo del personal de la empresa responsable de TI ], el [ fecha de celebración de la reunión ].
Los resultados marcados con un asterisco (*) se repiten de años anteriores.
[ Nombre del área de TI de control general (es decir, operaciones de sistemas de información, seguridad de la información,
o Gestión de control de cambios) –– Descripción breve de la actividad de control fallida ]
HALLAZGO
[ Descripción detallada del hallazgo. ]
[EJEMPLO: Durante el año fiscal que finalizó el 30 de junio de 20XX, la Compañía convirtió su
solicitud financiera de [Solicitud n. ° 1] a [Solicitud n. ° 2]. Notamos que la Compañía
no tenía políticas y procedimientos formales establecidos o documentados con respecto al cambio
proceso de gestión relacionado con la conversión de datos de sistemas antiguos a nuevos,
aplicaciones y bases de datos. ]
RIESGO
[ Descripción del riesgo de TI relacionado con el hallazgo anterior. ]
[EJEMPLO: No implementar los controles generales apropiados relacionados con la conversión de datos
puede resultar en interrupciones operativas, rendimiento degradado del sistema o seguridad comprometida. ]
RECOMENDACIÓN
[La recomendación del auditor se documenta aquí. ]
[EJEMPLO: La empresa debe documentar formalmente una política de control de cambios para establecer
procedimientos más cada cambio ' ciclo de vida s, incluidos los controles sobre las conversiones de datos. Recién
Las políticas desarrolladas también deben aprobarse, comunicarse y distribuirse formalmente para
usuarios. ]
RESPUESTA DE GESTIÓN
[ La gestión ' respuesta de s debe abordar la responsabilidad y la rendición de cuentas

implementación de una acción correctiva, así como también incluir una fecha de implementación
corrección. ]
[EJEMPLO: La administración reconoce y acepta la recomendación del auditor de TI. Un plan para
implementar controles de conversión de datos apropiados se implementarán y enviarán a nuestro
CEO y CFO para su revisión y aprobación dentro del próximo mes. Controles generales relacionados
a la conversión de datos se espera que estén diseñados y completamente operativos para el próximo
año ' auditoría de TI s. ]
Al recibir la carta de gestión, la dirección de TI y el personal afectado deben revisar la
documento de inmediato. Los elementos que aún no se hayan completado deben manipularse y seguirse.
Dentro de un tiempo relativamente corto, el hecho de que todas las discrepancias hayan sido corregidas debería
entregado al personal de auditoría de manera formal. Estas acciones se anotan en los archivos de auditoría, y tales
La cooperación se refleja favorablemente en futuras auditorías.
Página 117
I. Evaluación de riesgos
Vulnerabilidades
Activos del sistema Probabilidad Impacto Riesgo Controlar
y amenazas
caracterización determinación análisis determinación recomendaciones
identificación
II. Plan de auditoria

Equipo de auditoría,
Exhaustivo Riesgo Objetivos y Auditoría Presupuesto de auditoría
tareas, y
comprensión evaluación contexto calendario y alcance
plazos
IV. Resultados y comunicación
Documentar los resultados y garantizar los papeles de trabajo

son consistentes con las conclusiones de la auditoría
III. Procedimientos de auditoria
Prueba
Preliminar si Borrador de hallazgos y recomendaciones de auditoría
control S
revisión y y comunicarse con la gerencia para su revisión
Evaluar
diseño
¿control S?
auditoría Acordar los hallazgos con la gerencia y
Sustantivo
procedimientos No
pruebas documentar sus planes de respuesta y corrección
Emitir informe de auditoría
Figura 3.10 Resumen del proceso de auditoría.
Es importante realizar un seguimiento de las acciones correctivas para verificar que los hallazgos se hayan corregido. Es
Requiere un proceso formal para rastrear las acciones correctivas, las fechas objetivo y el estado para informar a TI.
la administración, el comité de auditoría y la junta.
Al cierre de la auditoría, se emite un borrador del Informe de Auditoría para que lo revisen todas las partes afectadas. lo
El proceso de revisión será mucho más rápido si los hallazgos ya han sido acordados con la gerencia durante
la fase de prueba y conclusión. Una vez finalizado el informe de auditoría, es una buena práctica
para programar una reunión final en la que participen tanto el departamento de TI como el financiero. Normalmente, las invi
reunión final se envían al CIO y al director financiero (CFO) (o al controlador si el director financiero
no está disponible) para discutir la auditoría, así como para revisar los objetivos de la auditoría y solicitar comentarios
sobre el desempeño del equipo auditor. Esta reunión proporcionará información valiosa al
desempeño del personal de auditoría y lecciones aprendidas para mejorar compromisos futuros.
Para resumir el proceso de auditoría explicado en este capítulo, consulte el Anexo 3.10.
Otros tipos de auditorías de TI

Además de respaldar las auditorías de estados financieros, existen otras áreas de auditoría muy demandadas:
canalizados en TI. Estos se describen brevemente a continuación.
Arquitectura empresarial
La gerencia de TI debe desarrollar procedimientos organizacionales para asegurar una gestión controlada y eficiente.
Arquitectura para el procesamiento de la información. Estos procedimientos también deben especificar las computadoras y
equipo periférico necesario para respaldar todas las funciones de manera económica y oportuna. Con
Página 118
Los sistemas empresariales son muy críticos para las empresas medianas y grandes de hoy, la necesidad de monitorear
tor y validar la integridad operativa de un sistema de planificación de recursos empresariales es un importante
proceso. La auditoría de TI juega un papel importante en el mantenimiento, la validación y el seguimiento de la empresa.
premio de arquitectura.
Sistemas y aplicaciones informáticos

Un tipo de auditoría computarizada de sistemas y aplicaciones verifica que los sistemas y
las aplicaciones (operativas y no financieras) son:
◾ adecuado a las necesidades de los usuarios,

◾ eficiente y
◾ adecuadamente controlados para garantizar una entrada, un procesamiento y un procesamiento válidos, confiables, opo
producción a los niveles actuales y proyectados de actividad del sistema.
Instalaciones de procesamiento de información

Una auditoría de la instalación de procesamiento de información asegura un procesamiento oportuno, preciso y eficiente de
aplicaciones en condiciones normales y potencialmente disruptivas.
Desarrollo de sistemas
Una auditoría de TI relacionada con el desarrollo de sistemas aseguraría que las aplicaciones y los sistemas
en desarrollo cumplir con los objetivos de la organización, satisfacer los requisitos del usuario y proporcionar
aplicaciones y sistemas eficientes, precisos y rentables. Este tipo de auditoría asegura que
Las aplicaciones y los sistemas están escritos, probados e instalados de acuerdo con las normas generalmente aceptadas.
estándares para el desarrollo de sistemas.
Planificación de la continuidad del negocio / Planificación de la recuperación ante desastres

Según el SysAdmin, Audit, Network, Security (SANS) Institute, una continuidad del negocio (o
resiliencia) (BCP) incorpora actividades y procedimientos para recuperar todas las operaciones comerciales (no
solo TI) de interrupciones o eventos adversos. * Un plan de recuperación ante desastres (DRP) incorpora un conjunto de
procedimientos para recuperar y proteger la infraestructura de TI de la organización en caso de una emergencia
o desastre. Ambos planes deben documentarse formalmente y mantenerse actualizados dentro de la organización.
Una auditoría de BCP evalúa cómo se gestionan los procesos de continuidad de una organización. Esta
El tipo de auditoría define los riesgos o amenazas para el éxito del plan y evalúa los controles establecidos.
para determinar si esos riesgos o amenazas son aceptables y están en línea con el objetivo de la organización
tives. † Esta auditoría también cuantifica el impacto de las debilidades del plan y ofrece recomendaciones
para mejorar el plan de continuidad del negocio.
Las auditorías de DRP ayudan a garantizar que la infraestructura de TI y todos los equipos relacionados utilizados para
probar, operar, monitorear, administrar y / o brindar soporte a los servicios de TI (por ejemplo, hardware, software, redes,
centros de datos, etc.) se mantienen y protegen adecuadamente para garantizar su disponibilidad continua
coherente con los objetivos de la organización. Una auditoría de DRP considera factores como el destino del sitio alternativo
encendido, capacitación de personal y temas de seguros, entre otros.
* www.sans.org/reading-room/whitepapers/recovery/introduction-business-continuity-planning-559.
† http://searchdisasterrecovery.techtarget.com/definition/business-continuity-plan-audit.
Página 119
Conclusión
Durante décadas, la computadora se ha utilizado para respaldar las operaciones diarias en entornos comerciales.
La mayoría de las empresas descubren que deben utilizar la tecnología informática de forma eficaz para seguir siendo compe
Sin embargo, la naturaleza de la tecnología sigue cambiando rápidamente. Como resultado, las empresas continúan
para integrar sus operaciones y sistemas contables / financieros. La profesión de auditor ha hecho
estos ajustes también. En todo el mundo, las organizaciones profesionales han emitido orientaciones útiles y
instrucción para ayudar a los gerentes y los profesionales de auditoría.
Si la auditoría de TI revisa las operaciones de los sistemas de información, la seguridad de la información o las aplicacio
cationes, los controles aplicados en esas áreas deben ser verificados. La función del auditor de TI (si
interno o externo) proporciona una seguridad razonable de que los activos del sistema están protegidos, la información
es oportuno y confiable, y los errores y deficiencias se descubren y corrigen con prontitud. Igualmente
Los objetivos importantes de esta función son controles efectivos, pistas de auditoría completas y cumplimiento.
con políticas organizacionales.
Indudablemente, la naturaleza de la auditoría seguirá experimentando cambios sustanciales a medida que
mejora el nivel de tecnología. Automatización completa desde el inicio del proyecto hasta el informe final
etapa permitirá a los auditores hacer un uso más eficiente de los recursos disponibles y mejorar la
credibilidad de la auditoría realizada. El uso eficaz de la tecnología informática también puede potenciar
auditores para comprender mejor el diseño del sistema informático del cliente, así como la conducta
auditorías exitosas en los entornos altamente automatizados de hoy.
1. ¿Qué es un universo de auditoría y qué incluye?
2. ¿Qué son los Objetivos de Control para la Información y Tecnología Relacionada (COBIT) y por qué
¿Es valioso para los auditores de gestión y de TI?
3. ¿Por qué las evaluaciones de riesgos son importantes para la función de auditoría?
4. Resuma la importancia de un plan de auditoría. ¿Cuáles son los cuatro pasos mínimos de una auditoría?
plan debe tener?
5. Indique la importancia de un programa de auditoría.
6. Describa qué debe incluir el alcance de una auditoría.
7. Describa brevemente las ocho fases típicas de un trabajo de auditoría.
8. ¿Qué información o evidencia específica puede recopilar un auditor de TI para un cliente que utiliza su
¿Entorno de TI para almacenar y procesar datos de importancia financiera?
9. Explique qué es un programa de auditoría.
10. Describa los procedimientos que realizan los auditores de TI para probar los controles, procesos y
exposiciones.
11. Describa los procedimientos que se suelen realizar al realizar una auditoría de TI relacionada con:
a. Desarrollo de sistemas
segundo. Planificación de la continuidad del negocio / Planificación de la recuperación ante desastres
Ejercicios
1. Como jefe de auditoría de TI del compromiso, presentará al gerente de TI y al socio
(como parte de la reunión de planificación) los resultados de la evaluación de riesgos realizada en el Cuadro 3.3.
Página 120
Con base en dichos resultados (consulte el Cuadro 3.3, bajo "Calificación de riesgo" y "Prioridad de acción"
columnas), parece claro que la auditoría debería centrarse en la Aplicación financiera n. ° 2 (FA2).
Sin embargo, el gerente de TI y el socio, basándose en la experiencia relevante previa, creen
que la auditoría debe realizarse en la Solicitud financiera n. ° 1 (FA1). La reunión de planificación
ha terminado y todavía tiene dudas sobre la decisión que acaba de tomar. Su tarea: preparar un documento de dos pág
memo al gerente de auditoría (copiando al socio) indicando sus razones por las que FA2 debe ser
auditado primero. Para convencer al director de auditoría y al socio, debe pensar "fuera de
la caja." En otras palabras, piense en información adicional no necesariamente documentada en el
evaluación de riesgos que se muestra en el Anexo 3.3, y documente en su memo la información relacionada con:
a. Cualquier vulnerabilidad o debilidad adicional que pueda existir actualmente que afecte a FA2
segundo. Cualquier fuente de amenaza adicional que pueda desencadenar las vulnerabilidades o debilidades que acab
identificado para FA2
C. Cualquier riesgo o situación adicional que implique exposición a pérdidas para la información financiera.
mación en FA2
re. Cualquier control o procedimiento adicional que deba implementarse para mitigar los riesgos.
recién identificado
2. Utilice la siguiente información para preparar un memorando de planificación de TI similar al de
Apéndice 1.
a. Usted es el sénior de auditoría de TI (o el representante del auditor de TI) asignado. Su firma de auditoría tiene
varias sucursales, pero está trabajando con este cliente en particular de Melbourne, FL
oficina.
segundo. La auditoría de TI apoyará la auditoría de los estados financieros de la Compañía XYZ, con una
año terminado el 31 de diciembre de 20XX.
C. Las discusiones con el Director de auditoría financiera sobre la participación en la auditoría de TI han
ya se llevaron a cabo y están documentados en el documento de trabajo (p / p) 1000.1. Los auditores de TI tienen
no ha estado involucrado en auditorías previas para este cliente.
re. Su equipo está compuesto por: IT Partner P, IT Manager M y IT Audit Staff AS. Usted está
el Senior de auditoría de TI S.
mi. El calendario de la auditoría incluye: La planificación se realizará durante el sexto mes de la
año bajo auditoría; Los procedimientos de auditoría intermedia se llevarán a cabo durante 2 meses antes de la
fin del año fiscal; Los procedimientos de fin de año están programados para enero a marzo de
el año siguiente al final del año fiscal; y todos los papeles de trabajo y documentación de auditoría
La notificación vence y se firma el 30 de abril del año siguiente al final del período fiscal.
año.
F. Se estima que la auditoría de TI durará 100 horas. Las horas se cargarán al código del cliente:
Compañía XYZ-0000.
gramo. La comprensión del entorno de TI de la empresa XYZ se documenta en la publicación 1540.
h. Las tres aplicaciones relevantes para la auditoría de TI incluyen:
yo. Toda la aplicación de contabilidad (AAA), utilizada para capturar y procesar la contabilidad
Transacciones Relacionadas. AAA está instalado en una plataforma UNIX (o sistema operativo),
y utiliza la base de datos Oracle. Se puede acceder a AAA a través de una red de Windows.
ii. Aplicación de generador de documentos financieros (FDGA): se utiliza para producir todo tipo de
informes financieros y documentación. FDGA está instalado en un sistema operativo Windows.
sistema y utiliza Oracle como base de datos. Se accede a FDGA a través de una red de Windows.
iii. Aplicación de recursos humanos y nómina (HRPA): se utiliza para administrar los
recursos humanos y proceso de nómina. Esta aplicación está alojada fuera del
pany, en una organización de terceros llamada HRP-For-All.
Página 121
yo. Los controles de aplicación relevantes utilizados para mitigar los riesgos en esta auditoría se enumeran en el Ane
3.5b (estos deben agregarse al Memo de planificación de TI). Utilice w / p 1000.2 como referencia
propósitos.
j. Las desviaciones o hallazgos resultantes de probar los controles de aplicación relevantes serán
documentado en w / p 2302.
k. No habrá trabajo de otros (por ejemplo, personal de Auditoría Interna, etc.) utilizado en la auditoría de TI.
l. Los servicios de recursos humanos y nómina son realizados por una organización de servicios de terceros
llamado HRP-For-All, ubicado en Austin, Texas. Deloitte, el auditor de servicios, acaba de terminar
emitir un informe de evaluación de los controles en la organización de servicios para el período 1 de julio,
20XX hasta el 30 de junio de 20XX. Se encontró que los controles en HRP-For-All eran efectivos.
metro. No hay otras áreas identificadas dentro de la Compañía XYZ en las que los auditores de TI puedan ayudar.
3. ¿Cómo se utilizan las pruebas sustantivas en una auditoría de TI? Explique qué significa el término auditoría-
a través de la computadora.
4. ¿Qué es un hallazgo de auditoría y qué información debe incluirse al documentarlo?
5. Usted es un auditor de TI externo al que se le solicitó que realice una revisión de lo siguiente:
La aplicación de transacciones (FTA) está causando un problema con la aplicación del libro mayor
(GLA) debido al momento de la transferencia de transacciones. Los datos fueron transferidos tarde por FTA
provocando que los informes de fin de mes se declaren incorrectamente. Los gerentes se reunieron para revisar antes
informes de actividad del mes, y notó un déficit de $ 50,000 en algunas cuentas. Preparar un
plan de auditoría para llevar a cabo procedimientos para abordar este tipo de situación.
Otras lecturas
1. AICPA. Análisis de auditoría y auditoría continua: mirando hacia el futuro, www.aicpa.org/
InterestAreas / FRC / AssuranceAdvisoryServices / DownloadableDocuments / AuditAnalytics_
LookingTowardFuture.pdf (consultado en agosto de 2017).
2. Benson, J. (agosto de 2007). La importancia del seguimiento . Auditor interno. Instituto de Interna
Auditores, Altamonte Springs, FL.
3. Berry, L. (octubre de 2007). Una auditoría más amable y gentil . Auditor interno. Instituto de Auditores Internos,
Altamonte Springs, FL.
4. Bodin, L., Gordon, L. y Loeb, M. (2008). Seguridad de la información y gestión de riesgos. Comun.
ACM , 51 (1), 64–68.
5. Casas, E. (octubre de 2007). Dígalo como es . Auditor interno. Instituto de Auditores Internos, Altamonte
Springs, FL.
6. Cavusoglu, H., Mishra, B. y Raghunathan, S. (2004). Un modelo para evaluar la inversión en seguridad de TI
mentos. Comun. ACM , 47 (1), 87–92.
7. Chaney, C. y Gene, K. (agosto de 2007). El Auditor Integrado . Auditor interno. Instituto de Interna
8. Deloitte LLP. (2014). Documentos de trabajo de planificación de auditoría de TI . Documento interno inédito.
9. Diez consideraciones de TI clave de EY para la auditoría interna: plan de auditoría y evaluación de riesgos de TI eficaz
ning. (Febrero de 2013). Información sobre gobernanza, riesgo y cumplimiento, www.ey.com/Publication/
vwLUAssets / Ten_key_IT_considerations_for_internal_audit / $ FILE / Ten_key_IT_considerations_
for_internal_audit.pdf
10. Flipek, R. (junio de 2007). Se encontraron faltas de habilidades de auditoría de TI . Auditor interno. Instituto de Auditores Intern
11. Gallegos, F. (2002). El informe de auditoría y seguimiento: métodos y técnicas para comunicar
conclusiones y recomendaciones de la auditoría. Inf. Syst. Control J. , 4, 17-20.
12. Gallegos, F. y Preiser-Houy, L. (2001). Revisión de aplicaciones de bases de datos de enfoque , serie de auditoría EDP,
74-10-23, Auerbach Publishers, Boca Raton, FL, págs. 1-24.
Página 122
13. Hyde, G. (agosto de 2007). Pruebas de auditoría mejoradas . Auditor interno. Instituto de Auditores Internos,
14. Fundación de Auditoría y Control de Sistemas de Información. COBIT , 5ta edición, Sistemas de información
15. Conceptos básicos de auditoría de SI. El proceso de auditoría de los sistemas de información , www.isaca.org/knowledge-center/
assurance-audit- / pages / is-audit-basics.aspx (consultado en julio de 2017).
16. Manson, D. y Gallegos, F. (septiembre de 2002). Auditoría de procedimientos de recuperación de DBMS , auditoría de EDP
Serie, 75-20-45, Auerbach Publishers, Boca Raton, FL, págs. 1–20.
17. Predicciones de amenazas de McAfee Labs 2017, informe publicado en noviembre de 2016, www.mcafee.com/au/
resources / reports / rp-amenazas-predictions-2017.pdf (consultado en octubre de 2017).
18. Informe de amenazas de McAfee Labs: diciembre de 2016, www.mcafee.com/ca/resources/reports/rp-quarterly-
amenazas-dec-2016.pdf (consultado en octubre de 2017).
19. McCafferty, J. (2016). Cinco pasos para planificar un programa de auditoría de TI eficaz , MIS Training Institute,
http://misti.com/internal-audit-insights/five-steps-to-planning-an-effective-it-audit-program
20. Menkus, B. y Gallegos, F. (2002). Introducción a la auditoría de TI , # 71-10-10.1, Auerbach Publishers,
Boca Raton, FL, págs. 1-20.
21. Base de datos nacional de vulnerabilidad. Instituto Nacional de Estándares y Tecnología, https: //nvd.nist.
gov / vuln / search (consultado en agosto de 2017).
22. Otero, AR (2015). Una metodología de evaluación de control de seguridad de la información para organizaciones '
información financiera. En t. J. Acc. Informar. Syst. , 18 (1), 26–45.
6 (3), 841–849.
24. Otero, AR, Tejay, G., Otero, LD y Ruiz, A. (2012). Una seguridad de la información basada en lógica difusa
evaluación de control para organizaciones, IEEE Conference on Open Systems, Kuala Lumpur, Malasia.
25. Otero, AR, Otero, CE y Qureshi, A. (2010). Una evaluación multicriterio de la seguridad de la información
controles que utilizan funciones booleanas. En t. J. Network Secur. Apl. , 2 (4), 1–11.
26. Pareek, M. (2006). Optimización de controles para realizar pruebas como parte de una estrategia de auditoría basada en riesgos. I
Control Assoc. J. , 2, 39–42.
27. Romney, MB y Steinbart, PJ (2015). Sistemas de información contable , 13a edición, Pearson
Educación, Upper Saddle River, Nueva Jersey.
28. Richardson, VJ, Chang, CJ y Smith, R. (2014). Sistemas de información contable , McGraw Hill,
Nueva York.
29. Plantillas de políticas de seguridad de la información de SANS, www.sans.org/security-resources/policies/general
30. Sarbanes-Oxley-101. Sección 404: Evaluación administrativa de controles internos, www.sarbanes-
32. Singleton, T. (2003). Las ramificaciones de la Ley Sarbanes-Oxley. Inf. Syst. Control J. , 3, 11–16.
33. Oficina de Contabilidad General de EE. UU., Evaluación de la confiabilidad de la confiabilidad de los datos procesados por com
digital.library.unt.edu/ark:/67531/metadc302511/ (consultado en noviembre de 2016).
34. Oficina de Contabilidad General de EE. UU. , Proyecto de Norma de Normas de Auditoría Gubernamental 2017 , www.gao.gov/
Yellowbook (consultado en mayo de 2017).
35. Oficina General de Contabilidad de EE. UU., Normas de control interno del gobierno federal , septiembre
2014, GAO / AIMD 00-21.3.1.
Página 123
Capítulo 4
Herramientas y técnicas
Utilizado en auditoría de TI
1. Definir herramientas de productividad del auditor y describir cómo ayudan al proceso de auditoría.
2. Describir las técnicas utilizadas para documentar los sistemas de aplicación, como los diagramas de flujo, y cómo
estas técnicas se desarrollan para ayudar al proceso de auditoría.
3. Explique qué son las técnicas de auditoría asistidas por computadora (CAAT) y describa la función que
jugar en el desempeño del trabajo de auditoría.
4. Describa cómo se utilizan las CAAT para definir el tamaño de la muestra y seleccionar la muestra.
5. Describa las distintas CAAT que se utilizan para revisar las aplicaciones, en particular, la auditoría
software de auditoría de lenguaje de mando (ACL).
6. Describa las CAAT utilizadas al auditar los controles de las aplicaciones.
7. Describa las CAAT utilizadas en las revisiones operativas.
8. Diferenciar entre "Auditoría en la computadora" y "Auditoría a través del
Computadora."
9. Describir la informática forense y las fuentes para evaluar las herramientas y técnicas informáticas forenses.
La tecnología informática se ha convertido en una parte integral de la mayoría de las funciones organizativas. Es probable qu
muchos clientes de auditoría han eliminado o eliminarán una parte sustancial de sus documentos en papel
y reemplazarlos con documentos electrónicos archivados solo en forma computarizada. Un auditor
Quien no pueda utilizar las herramientas y técnicas de auditoría computarizadas de manera eficaz estará en desventaja.
El auditor de hoy debe estar equipado con un conocimiento de herramientas y técnicas alternativas.
probar el funcionamiento de los sistemas informáticos y recopilar y analizar los datos contenidos en
archivos erizados. Los auditores pueden aprovechar esas herramientas y técnicas para ser más eficientes y
eficaz al realizar el trabajo de auditoría. Las herramientas y técnicas utilizadas en las auditorías de TI incluyen:
◾ Herramientas de productividad de auditoría: software que ayuda a los auditores a reducir la cantidad de tiempo dedica
tareas administrativas automatizando la función de auditoría e integrando la información recopilada
como parte del proceso de auditoría.
97
Página 124
◾ Técnicas de documentación del sistema: métodos, como diagramas de flujo, diagramas de flujo de datos y
diagramas de procesos de negocio aplicados a documentar y probar sistemas de aplicación, procesos de TI,
y su integración en el entorno de TI.
◾ Técnicas de auditoría asistidas por computadora (CAAT): software que ayuda a los auditores a evaluar
controles de seguridad, y seleccionar y analizar datos computarizados para pruebas de auditoría sustantivas.
Este capítulo comienza definiendo las herramientas de productividad del auditor y describiendo cómo ayudan al
proceso de auditoría. Este capítulo luego aborda las diversas técnicas utilizadas para documentar
sistemas de aplicación, en particular sistemas de aplicación financiera, y cómo ayudan a la auditoría
proceso. Las explicaciones de las CAAT y el papel que desempeñan en la auditoría seguirán junto con
descripciones de los distintos CAAT utilizados al definir el tamaño de la muestra de auditoría, seleccionar muestras y
revisar aplicaciones (por ejemplo, Audit Command Language (ACL), etc.). CAAT utilizados en auditoría
Los controles de la aplicación y en las revisiones operativas se describirán seguidos de explicaciones.
de auditar alrededor oa través de la computadora. Por último, herramientas y técnicas informáticas forenses.
son discutidos.
Herramientas de productividad de auditoría

El núcleo del proceso de auditoría es evaluar los controles internos para determinar si son efectivos o si es necesario
mejora. Sin embargo, muchas de las tareas asociadas con la realización de una auditoría, como la planificación,
probar y documentar los resultados, aunque es necesario, toma tiempo para realizar la
control del trabajo de evaluación. Aquí es donde entran en juego las herramientas de productividad del auditor. Auditoría de
Las herramientas de actividad ayudan a los auditores a automatizar las funciones de auditoría necesarias e integrar la inform
recopilados como parte del proceso de auditoría. Ejemplos de funciones de auditoría que pueden automatizarse mediante
Las herramientas de productividad del auditor incluyen:
◾ Planificación y seguimiento de auditorías

◾ Documentación y presentaciones
◾ Comunicación
◾ Gestión de datos, documentos de trabajo electrónicos y groupware
◾ Gestión de recursos
Planificación y seguimiento de auditorías

Desarrollar un universo de auditoría con todas las áreas de auditoría potenciales dentro de la organización, un riesgo
evaluación que prioriza estas áreas de auditoría, un programa de auditoría y un presupuesto para rastrear el progreso de la au
son algunas de las tareas necesarias en cualquier planificación de auditoría. Soluciones como hojas de cálculo, bases de dato
El software y / o el software de gestión de proyectos se pueden utilizar para documentar y planificar auditorías, así
como seguimiento de su estado actual. Sin embargo, cada una de estas soluciones es independiente, ya que su integración
puede que ni siquiera sea posible. Dado que las tareas de planificación son interdependientes, la productividad de un auditor
El software de herramienta que integra estas tareas de planificación y seguimiento proporcionaría una actualización y
Asegúrese de que todas las fases de la planificación se mantengan sincronizadas. Por ejemplo, el presupuesto debe proporcio
cientes costos para cumplir con el programa de auditoría, o el programa de auditoría no debe exceder los recursos
disponible, etc.
Página 125
Herramientas y técnicas utilizadas en la auditoría de TI ◾ 99
Documentación y presentaciones
Las herramientas, como la suite de Microsoft Office, proporcionan características para facilitar la creación y
presentación de documentos. Por ejemplo, datos de hoja de cálculo que contienen resultados de pruebas funcionales
se puede incorporar a un documento de informe con unos pocos clics del mouse. Estos mismos datos pueden
luego se copiarán en una diapositiva de presentación y también se vincularán, de modo que los cambios en la
Los comentarios se reflejarán en cualquiera de los documentos relacionados. Las herramientas de software como estas ahorr
garantizar la coherencia y la precisión. Otras herramientas incluyen videoconferencia y / o captura de video
software para proporcionar presentaciones a colaboradores en todo el mundo y para documentar evidencia de auditoría,
respectivamente.
Comunicación
Debido a que el auditor opera como parte de un equipo, la necesidad de compartir datos así como de comunicar
con otros miembros del grupo es importante. Proporcionar acceso inmediato a los datos actuales,
La mensajería tronic y las capacidades de revisión en línea permiten al personal de auditoría comunicarse y
recopilar información de investigación para auditorías y proyectos especiales. Además, los auditores pueden ocasionar
aliado necesita operar desde una terminal de computadora host, pero aún tiene toda la capacidad de un
procesador de escritorio. Por lo tanto, es necesario tener el hardware de computadora requerido, medios
software, controladores de protocolo, emuladores de software de terminal deseados y cableados o inalámbricos de alta veloc
conectividad en el sitio de auditoría.
La conectividad electrónica no solo permite que los auditores se comuniquen, sino que también proporciona acceso a
personal de gestión de la organización o clientes de auditoría para intercambiar información. Por ejemplo, cli-
El personal de gestión del ente o de la organización puede tener acceso al universo de riesgos de auditoría.
base de datos. Esto permite a la administración explorar la base de datos y sugerir cambios a la auditoría actual.
zonas de riesgo.
Las capacidades de videoconferencia también son una forma eficaz de comunicación. Videoconferencia
ing permite que se lleven a cabo reuniones y que los miembros participen en todo el mundo. Algunos de los mejores
El software de videoconferencia incluye Cisco WebEx Meeting Center, Citrix GoToMeeting y
Adobe Connect, entre otros. * El software de videoconferencia utiliza redes informáticas para transmitir
datos de video, auditoría y texto, suavizando el proceso de inicio y realización de conferencias en vivo
entre dos o más partes independientemente de su ubicación. A través de videoconferencias, participó
los pantalones pueden ver una hoja de cálculo, un gráfico o un videoclip; recibir feeds de datos en vivo; y ver las respuestas
todas las partes involucradas.
Gestión de datos, documentos de trabajo electrónicos y software colaborativo

El establecimiento de conectividad electrónica proporciona al personal de auditoría la capacidad de acceder y
Ingrese datos en un repositorio de datos central o base de conocimientos. El repositorio de datos central (p. Ej.,
base de datos, etc.) puede archivar riesgo histórico, programa de auditoría y datos presupuestarios a los que se puede acceder
electrónicamente por todos los usuarios autorizados en todo el grupo de auditoría, independientemente de su ubicación física
Se pueden desarrollar aplicaciones de bases de datos para consolidar automáticamente la entrada de datos de forma electróni
de todas las funciones de auditoría.
* www.pcmag.com/article2/0,2817,2388678,00.asp.
Página 126
Mediante el uso de bases de datos, la gestión de auditoría puede supervisar de forma centralizada y tener
acceso a actividades críticas como el estado del programa de auditoría, el estado de la auditoría de campo, el fraude o la esca
progreso de la formación y el desarrollo. Las aplicaciones de bases de datos pueden consolidar automáticamente
datos de toda la función y generar informes de estado y tendencias locales y consolidados. Los auditores pueden
producir productos más eficaces aprovechando el conocimiento de otros auditores al tener acceso
a los datos de toda la función.
Una base de datos puede contener información como áreas de riesgo, programas de auditoría, hallazgos,
procedimientos de acción, estándares de la industria, mejores prácticas y lecciones aprendidas. Esta información podría
estar disponible para la investigación cuando sea necesario. Además de los datos históricos, las bases de datos proporcionan
plataforma para actividades interactivas como tableros de mensajes o foros informáticos. Personal de auditoria
(y otros, si están autorizados) pueden publicar información nueva o actualizar información anterior. Del mismo modo, en lín
el almacenamiento de información permite a los auditores buscar información específica en documentos voluminosos
(p. ej., código de seguros, etc.), investigue un área de auditoría para determinar áreas de riesgo previas y
enfoques de prueba, identificar áreas relacionadas o interrelacionadas y revisar los enfoques locales o de toda la organización
planes de acción correctiva.
Los papeles de trabajo electrónicos o EWP también han transformado el proceso de auditoría en un
camino. Los EWP ofrecen un enfoque coherente para crear, documentar, revisar, compartir y almacenar
ing trabajo de auditoría. * Al crear y documentar EWP, los auditores pueden hacer referencia a su trabajo
evidencia, documentar los procedimientos de auditoría realizados y firmar electrónicamente su trabajo sin
esperando que otros miembros del equipo completen y firmen sus partes. Además, los EWP trabajan con
software de imágenes artísticas que permite la incorporación de imágenes escaneadas, correos electrónicos e imágenes digita
en el archivo como evidencia de auditoría. †
Los EWP también brindan acceso a la gestión de auditoría para navegar (de forma remota) a través de archivos de audit
Identificar el trabajo de auditoría completado, firmado y listo para revisión. Los revisores pueden agregar
notas, comentarios y / o preguntas en los archivos de auditoría que deberían abordarse y remitirse
a los encargados de trabajar con esos archivos. Al recibir los archivos de auditoría, los revisores verifican
y confirmar que todas las notas, comentarios y / o preguntas se hayan abordado adecuadamente antes
completando su revisión y firmando.
Mantener los EWP en un archivo de auditoría o una base de datos centralizados permite a los auditores navegar
y comparta fácilmente el trabajo de auditoría actual y archivado. Dicho archivo de auditoría centralizado o instalación de bas
establece el proceso para que los auditores accedan rápidamente al trabajo de auditoría anterior (por ejemplo, hallazgos, área
etc.) para coordinar los procedimientos de auditoría actuales.
El software colectivo o colaborativo es una herramienta especializada o conjunto de herramientas compatibles que
permite a los equipos comerciales trabajar más rápido, compartir más información, comunicarse de manera más efectiva y
realizar un mejor trabajo al completar las tareas. Los sistemas de trabajo en grupo crean un entorno de trabajo colaborativo
mentos. Hoy en día, estamos viendo conferencias de escritorio, videoconferencias, correo electrónico, tableros de mensajes
o foros, sistemas de apoyo a reuniones, sistemas de flujo de trabajo y calendarios de grupos y subgrupos como
ejemplos de herramientas de trabajo en grupo.
El software colaborativo es "natural" para automatizar la función de auditoría. Las herramientas de software colaborativ
características y procesamiento de flujo de trabajo que se pueden utilizar para almacenar e integrar la información recopilada
y se utiliza en el proceso de auditoría. Por ejemplo, la información de evaluación de riesgos alimenta la planificación de la a
los resultados de la auditoría alimentan los informes de auditoría y actualizan el modelo de evaluación de riesgos.
* www.wipo.int/export/sites/www/about-wipo/en/oversight/iaod/audit/pdf/annex_1.1_teammate_principles_
Guidelines.pdf.
† www.teammatesolutions.com/teamewp.aspx.
Página 127
Administracion de recursos
Otro desafío para los supervisores de auditoría es administrar una fuerza de trabajo remota. Si un personal audi
tor está trabajando en una auditoría local o en el campo, los gerentes deben poder brindar orientación
y revisar el trabajo a medida que avanza la auditoría. Los gerentes de auditoría deben proporcionar retroalimentación mientr
El auditor está en el lugar en caso de que sea necesaria una acción de seguimiento.
Una fuerza de trabajo distribuida requiere un equipo de gestión muy informado y receptivo que pueda
recopilar y difundir información rápidamente. La información importante se puede recopilar y
difundido en toda la función a través de correo electrónico y tableros de mensajes o foros informáticos. Supervisores
puede proporcionar retroalimentación y dirección inmediatas sobre proyectos de auditoría a través de la revisión en línea de
papeles de trabajo.
Técnicas de documentación del sistema para comprender

Sistemas de aplicación
Énfasis en comprender y documentar los sistemas de información de la organización / cliente.
es particularmente apropiado durante la fase de análisis de la aplicación de un trabajo de auditoría. Es
Es importante que el auditor comprenda la relación de cada aplicación con la realización de
el negocio de la organización o del cliente, y para documentar dicho entendimiento. Para esto, auditores
normalmente solicitan a las organizaciones o clientes los diagramas de relación de una entidad (ERD). Si está disponible,
Estos ERD son un excelente punto de partida para los auditores, ya que representan gráficamente la relación
entre "entidades" (o personas, objetos, lugares, conceptos, eventos, etc.) dentro del sistema de información
(es decir, sistema de aplicación financiera).
La documentación de los sistemas de información, en particular los sistemas de aplicación financiera, ayuda a los audito
contables, consultores, gerencia, etc. para comprender lo que está sucediendo financieramente en el
entidad y, lo más importante, cómo evaluar eficazmente esos sistemas. Los auditores también documentan
sistemas de aplicación financiera, según lo requieran las normas de auditoría, para comprender los
procedimientos manuales de control interno que utiliza la entidad. Al documentar los sistemas de aplicaciones financieras,
los auditores utilizan principalmente representaciones gráficas, ¿por qué? Se ha dicho que una imagen vale mil
palabras. Además, las imágenes tienden a ser fáciles de entender.
La documentación de los sistemas de aplicación se realiza habitualmente mediante narrativas, diagramas,
tablas, diagramas de flujo de datos, diagramas de procesos comerciales, diagramas de flujo, etc. Diagramas de flujo de datos
Los DFD, por ejemplo, están orientados a procesos y utilizan gráficos o símbolos para describir la transformación de datos.
ción y cómo fluye en toda la organización. Consulte el Anexo 4.1.
En el cuadro 4.1, los cuadrados o rectángulos representan fuentes o destinos de datos. Las flechas indican
flujos de datos, y el símbolo del círculo significa que se está llevando a cabo un proceso de transformación. Negocio
Los diagramas de procesos muestran visualmente las diversas actividades que se llevan a cabo en un proceso empresarial. Es
Los diagramas de proceso también muestran la unidad organizativa o el proceso (por ejemplo, nómina, cuentas por pagar, ef
desembolso, etc.) que realmente está realizando la actividad. Consulte el Cuadro 4.2.
En la Figura 4.2, los rectángulos redondeados representan las actividades o procedimientos que ocurren en un
proceso. El círculo indica el inicio de un proceso, mientras que el círculo en negrita indica el final de
el proceso. La flecha muestra el flujo de datos. La flecha punteada es la información de la anotación.
o información que ayude a explicar el proceso empresarial. Un tercer y más común ejemplo de
La documentación de los sistemas de aplicación financiera se realiza mediante diagramas de flujo. Similar al otro sistema
técnicas de documentación, los diagramas de flujo son una descripción gráfica de un sistema que representa cómo
Se realizan los procesos comerciales y cómo se realizan los diversos documentos dentro del proceso comercial.
Página 128
Financiero
Nómina de sueldos institución
cheque (banco)
Departamentos
Tarjeta de tiempo
dentro
información
organización
Empleado
Nómina de sueldos Empleados
cheques
Procesando
solicitud
Nuevo sistema
empleado
formar
Humano
Nómina de sueldos administración
recursos y
reporte
nómina de sueldos Existente
empleado
cambiar de forma
Informe fiscal
y Gobierno
pago
Figura 4.1 DFD que ilustra los procedimientos típicos de procesamiento de nóminas.
Empleado Actividades o trámites que tienen lugar
Factura de registros
Actualiza el diario A / P
Cuenta por pagar recibido de ven-
nal basado en C / D
(A / P) empleado dor en el A / P
diario
Sub.Ledger
Prepara el cheque para Actualiza el diario C / D

Desembolso de efectivo
liquidar proveedor con cancelado
(C / D) empleado
factura factura
Aprueba y firma
Desembolsa el cheque a
Tesorero cheque; cancela
el vendedor
factura
Figura 4.2 Ejemplo de un diagrama de proceso empresarial para un proceso de desembolso de efectivo.
fluir a través de la organización. Los diagramas de flujo utilizan símbolos para describir el procesamiento de transacciones y
flujo de datos a través de un sistema mostrando específicamente: entradas y salidas; actividades de información
( Procesando datos); almacenamiento de datos; flujos de datos; y pasos de decisión. Consulte el Anexo 4.3.
Las siguientes secciones se centran en la técnica de diagrama de flujo para documentar sistemas.
Página 129
Empleado de cuentas por pagar (A / P) Auxiliar de desembolsos de efectivo (C / D) Tesorero
Del proveedor
Factura Factura
Factura
Pre- Cheque
Cheque
pares
cheque
A/P
Registros Aprueba
Sub.
factura Cancelado y signos
libro mayor
factura
cheque;
cancela
factura
Factura Registros
pago
Cancelado
factura
Publicaciones
DISCOS COMPACTOS C / Ds Firmado
DISCOS COMPACTOS Cancelado cheque
diario cada factura
diario
viernes
Al vendedor
norte
A / P Sub.
libro mayor
Figura 4.3 Ejemplo de un diagrama de flujo para un proceso de desembolso de efectivo.
Diagramas de flujo como herramienta de análisis de auditoría

Los auditores preparan diagramas de flujo utilizando símbolos y técnicas estándar para representar los sistemas de aplicación
temas, flujos de trabajo o procesos. Diagramas de flujo desarrollados durante la fase de análisis de la aplicación de
un trabajo de auditoría son más útiles si distinguen el procesamiento según el departamento,
función o área de la empresa. Hay algunos paquetes de soporte de aplicaciones muy buenos para diagramas de flujo.
desarrollo, así como el poder del procesador de texto para construir diagramas e ilustraciones de
el proceso.
Para un auditor de TI, los diagramas de flujo representan un método para identificar y evaluar el control
fortalezas y debilidades dentro de un sistema de solicitud financiera bajo examen. Puede ser el momento
consumir para desarrollar una comprensión de las fortalezas y debilidades dentro de un sistema a auditar.
Sin embargo, la identificación de fortalezas y debilidades a menudo es crucial porque impulsarán la
dirección del resto de la auditoría (por ejemplo, fundamentar y determinar el efecto de los
controlar debilidades, etc.).
Por ejemplo, la Declaración sobre el estándar de auditoría (SAS) No. 109 requiere que el auditor obtenga un
posición de la entidad y su entorno y determinar los controles relevantes para la auditoría. los
El auditor debe tener conocimiento de la naturaleza y complejidad de los sistemas que forman parte de
el entorno de control que se audita (es decir, sistemas de aplicación financiera). Una forma de ganar
esa comprensión es a través de cualquier documentación existente que pueda proporcionar una ilustración visual
del sistema bajo revisión y cualquier interacción con otros sistemas. Cualquier documentación existente,
como los diagramas de flujo, proporciona un punto de referencia para la revisión del auditor.
Página 130
Como un paso hacia la construcción de la comprensión necesaria de las debilidades de control, el personal de auditoría
Debería desarrollar un diagrama de flujo de toda la información procesada. Los diagramas de flujo deben abarcar
toda la información procesada, desde los documentos originales hasta los resultados finales. Ya sea automatizado o manual
Se pueden utilizar técnicas para preparar estos diagramas de flujo. Con cualquiera de los dos enfoques, el proceso conduce a
la evaluación de una serie de elementos de un sistema, incluidos los siguientes:
◾ Calidad de la documentación del sistema

◾ Adecuación de los controles manuales o automatizados sobre documentos
◾ Efectividad del procesamiento por programas de computadora (es decir, si el procesamiento es necesario
o redundante y si la secuencia de procesamiento es adecuada)
◾ Utilidad de los resultados, incluidos informes y archivos almacenados
Los símbolos comunes de los diagramas de flujo se describen en la figura 4.4. Los siguientes son pasos en el desarrollo
de diagramas de flujo.
Comprender cómo procesan los datos las aplicaciones

El auditor debe comprender cómo el sistema de aplicación financiera, por ejemplo, genera su
datos. Este entendimiento debe abarcar todo el alcance del sistema financiero desde la preparación
Ración de los documentos fuente a la generación final, distribución y uso de los productos. Mientras aprende
cómo funciona el sistema, el auditor debe identificar las áreas potenciales de prueba, utilizando una auditoría familiar
procedimientos, tales como:
◾ Revisión de la documentación corporativa, incluidos los archivos de documentación del sistema, preparación de entrad
instrucciones de instalación y manuales de usuario
◾ Entrevistar al personal de la organización, incluidos usuarios, analistas de sistemas y programadores.
◾ Inspeccionar, comparar y analizar registros corporativos
Identificación de documentos y su flujo a través del sistema

Para comprender el flujo de documentos, se debe obtener cierta información previa a través de
siones con funcionarios corporativos, de auditorías o evaluaciones anteriores, o de la documentación del sistema
archivos. Debido a que esta información puede no estar actualizada o completa, debe verificarse con el
personal apropiado (por ejemplo, contabilidad, TI, etc.). Un usuario o miembro del personal del departamento de TI
Puede que ya tenga un diagrama de flujo del documento o un diagrama de flujo que muestre el origen de los datos y cómo
fluye hacia y desde la aplicación. Este diagrama no debe confundirse con un sistema
diagrama de flujo que muestra la relación entre la entrada, el procesamiento y la salida en un SI o un pro-
diagrama de flujo de gramo que muestra la secuencia de operaciones lógicas que realiza una computadora mientras se ejecut
un programa.
Si no está disponible, los auditores deberán desarrollar diagramas de flujo de documentos. El flujo de documentos
el diagrama debe incluir:
◾ Fuentes y documento (s) fuente, por título y número de identificación, con copias de los formularios
adjunto
◾ Punto de origen de cada documento fuente
◾ Cada unidad operativa u oficina a través de la cual se procesan los datos
◾ Destino de cada copia de los documentos de origen
Página 131
Figura 4.4 Símbolos comunes del diagrama de flujo
Símbolo Descripción
Documento manual o electrónico.
Varias copias de documentos manuales o electrónicos.
Dispositivo de entrada de datos electrónicos (por ejemplo, computadora portátil, dispositivo móvil, etc.)
La operación electrónica o el procesamiento de datos que tiene lugar por el

computadora.
Manual de operación.
Datos almacenados electrónicamente en base de datos.
Indica cómo se archivan los documentos en papel. Normalmente, N significa por

norte
número; D significa por fecha; y A significa alfabéticamente.
Datos almacenados electrónicamente en cinta magnética (generalmente para respaldo

propósitos).
Indica un tipo de diario manual o libro mayor.
Indica la dirección de un documento o flujo de procesamiento.
Conector en la página utilizado para vincular los flujos de procesamiento dentro del
misma página.
Conector fuera de página para indicar la entrada o salida a otra página.

Se utiliza en un proceso para indicar un comienzo, un final o un punto de
interrupción.
Se está tomando una decisión.
Página 132
◾ Acciones tomadas por cada unidad u oficina en la que se procesan los datos (por ejemplo, preparados, registrados,
publicado, archivado, etc.)
◾ Controla la transferencia de documentos fuente entre unidades u oficinas para asegurar que no
los documentos se pierden, agregan o cambian (por ejemplo, verificaciones, aprobaciones, recuentos de registros, con
totales, totales aritméticos de datos importantes, etc.)
◾ Destinatarios de salidas informáticas
Definición de elementos de datos

El auditor debe tener una comprensión clara de los datos que se registran en la solicitud de
propósitos de definición. Al definir elementos de datos individuales, los títulos pueden ser engañosos. Por ejemplo,
¿Se deriva un costo del período actual o es acumulativo? ¿Se acumula o se incurre en el costo? Qué
Cuáles son los componentes de un costo? Utilice nombres descriptivos al definir elementos de datos y verbos de acción
para procesos (por ejemplo, actualizar, preparar, validar, etc.). El diccionario de elementos de datos de la organización es un
buena fuente para tales definiciones. Si un diccionario de datos no está disponible, un diseño de registro puede contener
las definiciones necesarias.
Desarrollo de diagramas de flujo

Las entradas a partir de las cuales se preparan los diagramas de flujo deben incluir copias de lo siguiente:
◾ Descripciones narrativas de todos los principales sistemas de aplicación

◾ Todos los documentos fuente preparados manualmente que afecten el procesamiento de la solicitud, así como
responder hojas de codificación e instrucciones para la transcripción de datos
◾ Diseños de registro para todos los principales registros de entrada y salida de computadora, archivos maestros de comp
archivos de trabajo (como cintas de actualización o mantenimiento de archivos y cintas de cálculo)
◾ Todos los productos principales producidos por el sistema de aplicación
◾ Listas de códigos estándar, constantes y tablas utilizadas por la aplicación
Estos documentos, junto con la información desarrollada en las tareas anteriores, deberían permitir al
personal de auditoría para preparar un diagrama de flujo detallado y bien entendido.
Evaluación de la calidad de la documentación del sistema

Sobre la base de las aportaciones de los usuarios y del personal de TI, así como del grado de dificultad experimentado en
Al construir un diagrama de flujo, el auditor debe poder comentar sobre la calidad de la documentación del sistema.
mentación. Hay dos preguntas básicas que responder: ¿Es precisa la documentación? ¿Es el docu-
Mentación completa?
Parapodría
él o ella ilustrar, si un
usar auditor federal
el Manual estuviera
de Auditoría examinando
de Controles problemasdedeInformación
de Sistemas control en una instalación
Federal informática
(FISCAM) del de la Marin
Oficina de Responsabilidad del Gobierno de EE. UU. (GAO). Esta publicación proporciona una base para evaluar la
cumplimiento de los controles del sistema de información con las pautas federales.
Evaluación de controles sobre documentos

Los puntos de control en los diagramas de flujo deben identificarse y evaluarse. Revisando un diagrama
de este tipo, el auditor puede determinar si se han utilizado controles y, de ser así, resaltar
Página 133
brechas, fortalezas y debilidades dentro del sistema. Controles identificados, incluidos automatizados y
Los controles de aplicaciones dependientes de TI deben diseñarse e implementarse adecuadamente para
mitigar los riesgos. También deben evaluarse para determinar si abordan posibles errores
o prevenir / detectar transacciones no autorizadas que podrían resultar en un error material
Estados financieros. Un ejemplo de un control común incluye la verificación de coincidencia de tres vías
entre la factura del proveedor, la orden de compra y el informe de conciliación que realiza el
sistema como confirmación antes de que se libere el pago. Otros ejemplos de controles incluyen rendimiento
realizar verificaciones y aprobaciones, así como configurar el sistema para identificar las transacciones que caen
fuera de los rangos tolerables definidos. Si se identifican estas transacciones, un control adecuado
Impedir su procesamiento.
Determinación de la eficacia del procesamiento de datos

El personal de auditoría debe determinar qué tan efectivo es el procesamiento de datos identificando áreas problemáticas,
como los siguientes, en el ciclo de procesamiento:
◾ Procesamiento redundante de datos u otras formas de duplicación

◾ Puntos de cuello de botella que retrasan o congestionan el procesamiento
◾ Puntos en el ciclo operativo en los que los empleados no tienen tiempo suficiente para revisar la salida
informes y hacer correcciones
Tras la identificación, el auditor debe hacer recomendaciones sobre cómo abordar estos
Areas problemáticas.
Evaluación de la precisión, integridad y utilidad de los informes

El personal de auditoría debe revisar los resultados clave o principales (por ejemplo, editar listados, listados de errores, contr
listados, etc.) del sistema de solicitud financiera y determinar si los resultados son precisos,
completo y útil según lo previsto. El auditor debe confirmar la exactitud, integridad y utilidad
nidad de los informes generados entrevistando a los usuarios apropiados. Una técnica adecuada podría ser
la cumplimentación de un cuestionario o encuesta, quizás realizada por correo electrónico, sobre la satisfacción del usuario
con informes de salida.
Idoneidad de las técnicas de diagrama de flujo

Cabe señalar una distinción entre el uso de diagramas de flujo en la auditoría informática y en la
campo más amplio del análisis de sistemas. En los últimos años, los analistas de sistemas han comenzado a favorecer otros m
ods de modelado y documentación. Los DFD, por ejemplo, a menudo se prefieren a los diagramas de flujo para
propósitos de análisis (ver Anexo 4.1). Como se indicó anteriormente, los DFD están orientados a procesos y enfatizan
flujos lógicos y transformaciones de datos. Por el contrario, los diagramas de flujo enfatizan los procesos físicos
pasos y controles de ing. Sin embargo, este tipo de visión orientada al control es la que tiene el auditor.
Enfoque primario. Por lo tanto, aunque el uso de diagramas de flujo puede estar disminuyendo para el desarrollo de sistemas
Para fines, esta herramienta de modelado sigue siendo importante para los auditores de TI.
El diagrama de flujo no siempre es necesariamente el enfoque más práctico para el auditor. Existente
La documentación que incluye DFD, narrativas o descripciones de programas en pseudocódigo puede ser
utilizados como puntos de partida. Basado en una revisión de la documentación existente, el auditor puede decidir
Página 134
qué modelos adicionales se necesitan para obtener una comprensión adecuada de la aplicación financiera
sistemas bajo examen.
El auditor también debe ser consciente del uso creciente de técnicas automatizadas en la preparación
diagramas de flujo. Hay paquetes de software disponibles, muchos de los cuales se ejecutan en mainframes y microcomputa
ers que aceptan el código fuente del programa como entrada y generan diagramas de flujo terminados. Además, microordena
Los paquetes de software basados ahora disponibles pueden ayudar en la documentación o verificación de hojas de cálculo o
aplicaciones de bases de datos, por ejemplo.
La técnica para la segregación departamental del procesamiento en la preparación de diagramas de flujo.
es importante. Departamentos de segregación (por ejemplo, cuentas por pagar, desembolsos de efectivo, tesorero,
Cuentas por cobrar, etc.) en columnas verticales al crear diagramas de flujo muestran el procesamiento por
función o departamento. Esta representación es útil porque uno de los controles importantes
El auditor evalúa es la separación de funciones dentro del sistema de contabilidad financiera. Estructuración
diagramas de flujo de esta manera ayuda a disciplinar el pensamiento del auditor e identificar cualquier incompatibilidad
funciones que pueden existir dentro de las aplicaciones financieras. Esta segregación también ayuda a documentar
el papel de TI en el inicio, autorización, registro, procesamiento y reporte de transacciones
manejado por la aplicación.
En la figura 4.3 se muestra un ejemplo de un diagrama de flujo para un proceso de desembolso de efectivo. El siguiente
Lowing describe los pasos resumidos que tienen lugar en el proceso y se utilizan para crear el diagrama de flujo:
1. El proveedor envía la factura a la empresa por los servicios de consultoría empresarial.

2. La factura se envía al encargado de cuentas a pagar (A / P) de la empresa para su registro.
3. El empleado de acreedores registra manualmente la factura en el libro mayor auxiliar de acreedores.
4. Luego, la factura se envía al Secretario de Desembolso de Efectivo (C / D) de la Compañía para su procesamiento.
5. El secretario de C / D prepara un cheque para liquidar la factura, luego envía tanto el cheque como la factura al
Tesorero de la empresa.
6. El tesorero revisa ambos documentos, luego aprueba y firma el cheque. El tesorero también marca el
factura como cancelada (aquí se realizan varios controles).
7. El tesorero luego envía el cheque al vendedor y reenvía la factura cancelada al
Secretario C / D para registrar el pago o desembolso de efectivo en el diario C / D.
8. La factura cancelada se archiva luego por número (representado como " N " en el diagrama de flujo).
9. Cada viernes, el secretario de A / P contabiliza manualmente los pagos del diario C / D en el A / P
libro mayor subsidiario.
Al crear o revisar diagramas de flujo que describan los procesos de negocio, el auditor debe estar
mular notas que se considerarán para su posterior inclusión como comentarios en una carta de recomendaciones
a la organización o al personal de gestión de clientes. Al finalizar la revisión, el equipo de auditoría
informa al personal de gestión asociado con la auditoría. Todas las partes responsables deben tener una clara
comprensión de las fuentes y procedimientos descritos en el desarrollo del diagrama de flujo, y
en última instancia, cómo se reflejan en los estados financieros sobre los que la firma de auditoría emitirá una opinión
ion. Al completar dicha revisión, el equipo de auditoría debería haber adquirido un entendimiento que incluya:
◾ Establecimiento de fuentes para toda la información contable de importancia financiera.

◾ Identificar los pasos de procesamiento, particularmente de los puntos dentro de las aplicaciones en los que
se producen cambios en la información contable
◾ Determinar y comprender los resultados del procesamiento
◾ Analizar la naturaleza y el progreso de las pistas de auditoría en la medida en que existan y puedan
seguido en aplicaciones individuales
Página 135
Técnicas de auditoría asistidas por computadora (CAAT)

Otro tipo de técnicas de software utilizadas en las auditorías de TI son las CAAT. Como se mencionó en un
capítulo, el Instituto Americano de Contadores Públicos Autorizados emitió SAS No. 94, “El efecto
de tecnología de la información sobre la consideración del auditor del control interno en un
Auditoría de declaraciones ". Este SAS no cambia el requisito de realizar pruebas sustantivas en
cantidades significativas, pero afirma: “No es práctico ni posible restringir el riesgo de detección a un
nivel capaz realizando sólo pruebas sustantivas ". Al evaluar la eficacia del diseño y
operación de los controles de TI, es necesario que el auditor (TI o auditor financiero) evalúe y pruebe
estos controles. La decisión de evaluar y probar no está relacionada con el tamaño de la organización sino con
la complejidad del entorno de TI.
Los CAAT pueden ser utilizados por auditores financieros o de TI de diversas formas para evaluar
integridad de una aplicación, determinar el cumplimiento de los procedimientos y monitorear continuamente
procesamiento de resultados. Los auditores de TI, por ejemplo, revisan las aplicaciones para comprender mejor
los controles establecidos para garantizar la precisión y la integridad de la información generada.
Cuando se identifican los controles de aplicación adecuados, el auditor de TI realiza pruebas para verificar su
diseño y eficacia. Cuando los controles no son adecuados, los auditores de TI realizan pruebas exhaustivas
para verificar la integridad de los datos. Para realizar pruebas de aplicaciones y datos, el auditor puede
utilizar CAAT.
Las técnicas automatizadas han demostrado ser mejores que las técnicas manuales cuando se enfrentan
con grandes volúmenes de información. El auditor, mediante el uso de técnicas automatizadas, puede evaluar
mayores volúmenes de datos y realizar análisis de datos rápidamente para obtener una visión más amplia de un proceso.
Los CAAT comunes como ACL y Extracción y análisis de datos interactivos (IDEA) se pueden utilizar para
seleccionar una muestra, analizar las características de un archivo de datos, identificar tendencias en los datos y evaluar los d
integridad. Otras técnicas utilizadas para analizar datos incluyen, por ejemplo, Microsoft Access y
Microsoft Excel. Microsoft Access se puede utilizar para analizar datos, crear informes y consultar archivos de datos.
Microsoft Excel también analiza datos, genera muestras, crea gráficos y realiza regresiones o
análisis de tendencia. Gestión de auditoría de SAP (parte del software de aseguramiento y cumplimiento de SAP
que viene encapsulado con SAP GRC) también agiliza el proceso de auditoría al proporcionar costos
alternativas eficaces a las hojas de cálculo y las herramientas manuales. * SAP Audit Management facilita la
documentación de evidencias, organización de papeles de trabajo y elaboración de informes de auditoría. Esta
La técnica también proporciona capacidades analíticas para cambiar el enfoque de las auditorías de aseguramiento básico a
proporcionando información y consejos. †
Una gran parte de las habilidades profesionales necesarias para utilizar CAAT radica en planificar, comprender,
y supervisar (por ejemplo, SAS No. 108 — Planificación y supervisión, etc.) estas técnicas de auditoría,
y realización de las funciones y pruebas de auditoría adecuadas. La computadora tiene una amplia gama de
Capacidades A modo de ilustración, tres amplias categorías de funciones de auditoría informática pueden
ser identificado:
◾ Elementos de interés de auditoría
◾ Auditar matemáticas
◾ Análisis de datos
* www.complianceweek.com/blogs/grc-announcements/sap-delivers-new-audit-management-tool-for-internal-
equipos-de-auditoría # .WEhtkE0zW72.
† https://www.sap.com/products/audit-management.html.
Página 136
Elementos de interés de auditoría

El auditor puede utilizar la computadora para seleccionar elementos de interés, tales como elementos materiales, elementos i
o muestras estadísticas de elementos, por ejemplo, estipulando criterios específicos para la selección de
elementos de muestra, o indicando criterios relativos y deje que la computadora haga la selección.
Un ejemplo de selección por criterios específicos podría ser una especificación de que la computadora identifica
realiza todas las transacciones de $ 100,000 o más y prepara un informe que incluye dichas transacciones para
revisión de auditoría. Sin embargo, el auditor podría adoptar un enfoque relativo e instruir a la computadora para
seleccione las transacciones más grandes que representen el 20% del volumen total en dólares para una aplicación determina
Este enfoque abrevia los procedimientos manuales de auditoría porque el auditor puede confiar en los
selección de artículos de interés. Si no se usaran computadoras, el auditor tendría que validar la
proceso de selección. Bajo enfoques tradicionales, por ejemplo, sería común que un auditor
pedir a la organización o al personal del cliente que enumere todas las transacciones de $ 100,000 o más. Con el
ordenador, el auditor puede estar satisfecho de que el CAAT utilizado ha examinado el universo total de cuentas
partidas pagaderas, por ejemplo. La validación del proceso de selección es inherente al auditor
desarrollar y aceptar el programa de aplicación de auditoría informática.
Matemáticas de auditoría
Realizar extensiones o cimentaciones puede ser un área de recompensa rentable para la aplicación de
computadoras en auditoría, particularmente si los cálculos se pueden realizar como un subproducto de otra
función de auditoría. Por ejemplo, suponga que se utiliza la computadora para seleccionar elementos importantes de
un archivo de cuentas por cobrar. En el proceso de mirar este archivo, la computadora se puede programar
para ampliar y pagar todas las transacciones de facturación. Debido a la velocidad de la computadora, estos cálculos
Las operaciones se pueden realizar en el 100% de los elementos de un archivo sin una adición significativa de tiempo o cost
para este procesamiento.
Por el contrario, las extensiones y las zapatas son tediosas y costosas con el manual convencional.
técnicas de examen. Normalmente, el auditor debe limitar el examen de cualquier aplicación dada a
extensión y base de una muestra de juicio que cubre unos pocos intervalos cortos del período bajo
examen. Claramente, la confianza puede ser mucho mayor cuando se realizan estos cálculos de verificación
en archivos completos.
Sin embargo, recuerde que la computadora tiene limitaciones en esta área. Aunque puede ser pro-
gramatizado para hacer muchas comparaciones y pruebas lógicas, la computadora no puede suplantar a los humanos
juicio al examinar los elementos que se van a probar.
Análisis de los datos

El uso de la computadora para el análisis de datos representa una gran oportunidad de innovación por parte del
auditor. La computadora puede comparar y resumir datos y puede representar datos en forma gráfica.
Los programas de análisis de datos utilizan técnicas como:
◾ Histogramas
◾ Modelado
◾ Análisis comparativo
Los histogramas son gráficos de barras que muestran relaciones gráficas entre estratos de datos. En computadora-
auditoría asistida, los histogramas típicamente representan distribuciones gráficas de frecuencia de registros dentro
Página 137
archivos de información. Al representar estas relaciones en forma gráfica, los histogramas le dan al auditor una mejor
perspectiva sobre el análisis de estados financieros. El histograma es, en efecto, una instantánea que muestra
el contenido, la composición y la distribución de los datos dentro de la contabilidad o las finanzas de una organización
sistema. Consulte la figura 4.5 para ver un ejemplo de histograma.
Los auditores pueden aplicar su juicio al identificar y seleccionar las técnicas de prueba adecuadas.
usando histogramas. En comparación, dada una gran colección de datos sobre los cuales dicha distribución
Los datos no son conocidos, el auditor realiza las pruebas de forma relativamente ciega. En tales casos, la auditora
Tor no puede estar seguro de la importancia de los datos hasta que la prueba esté bien avanzada. Con un histograma,
elementos de importancia para la prueba se pueden identificar de antemano porque su relación con el
El universo contable se enfatiza gráficamente.
El modelado es una técnica mediante la cual el auditor puede comparar datos actuales con una tendencia o patrón.
como base para evaluar la razonabilidad. Consulte el Cuadro 4.6 para ver una ilustración de una comparación.
modelo. Los ejemplos de modelos comunes desarrollados por auditores se basan en varios años de
declaraciones. La computadora puede generar un estado financiero pro forma basado en ingresos pasados
o relaciones de costos. El estado pro forma se compara con los estados financieros reales como
una prueba de razonabilidad.
Ambas técnicas, histogramas y modelado, agregan nuevo contenido y dimensiones de información.
ción al proceso de auditoría mediante el uso de la computadora. Con estos métodos, el auditor
ya no se limita simplemente a validar los datos proporcionados por la organización o el personal del cliente. Con
Estas técnicas automatizadas, el auditor genera cifras o instantáneas de datos financieros para probar la
razonabilidad de las representaciones bajo examen.
El análisis comparativo, otra técnica común utilizada en el análisis de datos, es un costo comprobado
Examen de auditoría eficaz que implica la comparación de conjuntos de datos para determinar relaciones.
que pueden ser de interés para la auditoría. Consulte el Cuadro 4.7 para ver una ilustración de un ingreso comparativo.
análisis de declaraciones.
Otros ejemplos comunes de análisis de datos usan la computadora para comparar archivos de inventario de
años anteriores y actuales. Las grandes variaciones en los saldos de fin de año podrían conducir a revisiones de posibles
obsolescencia. El hecho de no coincidir con los números de pieza de los años anterior y actual podría provocar
procedimientos de prueba para determinar si se han eliminado elementos antiguos o se han agregado nuevos.
Producto de la empresa A Histograma de ventas por región

Trimestre finalizado el 31 de diciembre de 20XX
70
60
50
40
30
Ventas (millones)
20
10
0
norte Sur Este Oeste
Región de la empresa
Figura 4.5 Ejemplo de histograma.
Página 138
Producto de la empresa A Modelo de comparación de ventas por región

Trimestre finalizado el 31 de diciembre de 20XX
70
60
Industria
50
Empresa
40
30
Ventas (millones)
20
10
0
norte Sur Este Oeste
Región de la empresa
Figura 4.6 Ejemplo de un modelo de comparación.
Figura 4.7 Ejemplo de un análisis comparativo del estado de resultados
Compañía XYZ
Estado de resultados comparativo
Para los años terminados el 31 de diciembre de 20X1 y 20X2 (en miles excepto porcentaje)
20X1 20X2 Aumentar Disminuir)
Cantidad Cantidad Cantidad Por ciento
Ventas $ 840.0 $ 600 $ 240.0 40,0
Costo de los bienes vendidos 724,5 525 199,5 38,0
Beneficio bruto $ 115.5 $ 75 $ 40.5 54,0
Gastos de venta 52,5 37,5 15.0 40,0
Gastos administrativos 41,4 30 11,4 38,0
Gastos totales de operación $ 93.9 $ 67.5 $ 26.4 39,1
Utilidad antes de impuestos sobre la renta 21,6 7.5 14.1 188,0
Ingreso por gastos de impuesto 10,8 2,7 8.1 300,0

Lngresos netos $ 10,8 $ 4.8 $ 6.0 125,0
El análisis de datos, crítico para realizar funciones y pruebas de auditoría, debe seguir un
Comprensión completa del sistema de TI del cliente (es decir, sistema de información contable). SAS
No. 109, "Comprensión de la entidad y su entorno ...", refuerza la declaración anterior, y
requiere que los auditores comprendan el entorno del cliente, que incluye su contabilidad y
sistemas informáticos financieros. Los auditores suelen emplear CAAT cuando comprenden y examinan estos
tipos de sistemas de TI.
Página 139
CAAT para muestreo

Algunas técnicas de auditoría ayudan a definir el tamaño de la muestra y a seleccionarla. Por ejemplo, ACL
calcula automáticamente el tamaño de la muestra y selecciona una muestra de una población. Hoja de cálculo
Las aplicaciones también generan números aleatorios para seleccionar una muestra. Hay dos tipos de muestreo
técnicas:
◾ Muestreo de juicio : la muestra seleccionada se basa en el conocimiento y la experiencia del auditor.

ence. El juicio puede ser seleccionar un bloque de tiempo, una región geográfica o una función específicos.
◾ Muestreo estadístico : la muestra se selecciona al azar y se evalúa a través de la aplicación
de la teoría de la probabilidad.
Ambos métodos permiten al auditor proyectar a la población. Sin embargo, solo el muestreo estadístico
permite al auditor cuantificar el riesgo de que la muestra no sea representativa de la población. los
El método específico seleccionado para una muestra dependerá de los objetivos de la auditoría y las características.
de la población. La idoneidad del método seleccionado debe revisarse para verificar su validez.
propósitos por personal estadístico o actuarial con experiencia en esta área. Además, el muestreo aplicado
El método debe ser revisado y reevaluado con el tiempo para ver si hay algún cambio en el carácter.
isticos o atributos de la poblacin analizada. Dos métodos de muestreo estadístico comunes son:
Muestreo de atributos aleatorios y muestreo variable.
Muestreo de atributos aleatorios y muestreo variable

El muestreo de atributos aleatorios es una técnica estadística que prueba atributos específicos predefinidos
de transacciones seleccionadas aleatoriamente de un archivo. Atributos para los que se realizan tales pruebas
podría incluir firmas, distribución de cuentas, documentación y cumplimiento de políticas y
procedimientos. Para realizar el muestreo de atributos, el auditor debe especificar tres parámetros que determinen
tamaño de la muestra mía:
1. Estime la "tasa de error esperada", o porcentaje estimado de transacciones de excepción, en el

población total.
2. Especifique la "precisión" requerida, o el grado de exactitud deseado, de la conclusión de la muestra para
hacerse.
3. Establezca un "nivel de confianza" aceptable de que la conclusión extraída de la muestra
ser representativo de la población.
El tamaño de la muestra vendrá determinado por la combinación de la tasa de error esperada, precisión,
y parámetros de nivel de confianza.
El muestreo variable es otra técnica estadística que estima el valor en dólares de una población.
ción o alguna otra característica cuantificable. Para determinar el tamaño de la muestra usando muestra variable
pling, el auditor debe especificar cuatro parámetros:
1. "Nivel de confianza" aceptable de que la conclusión extraída de la muestra será representativa

tivo de la población.
2. Valor absoluto de la "población" del campo que se muestrea.
3. “Materialidad” o cantidad máxima de error permisible en la población sin detección.
4. “Tasa de error esperada” o porcentaje estimado de transacciones de excepción en la población total.
Página 140
El tamaño de la muestra se determinará mediante la combinación de los cuatro parámetros enumerados anteriormente.
El Cuadro 4.8 describe otras técnicas de muestreo estadístico comúnmente utilizadas. De nuevo, el auditor
debe estar atento a los cambios y actualizaciones de la guía en el uso del muestreo para realizar el trabajo de auditoría.
Un buen ejemplo es SAS No. 111 (Enmienda a la Declaración sobre el Estándar de Auditoría No. 39, Auditoría
Muestreo). SAS No. 111 aborda los conceptos de establecer "tasas de desviación tolerables" cuando
prueba de muestreo de controles como el emparejamiento y la autorización. También define el uso apropiado
del muestreo de doble propósito.
Figura 4.8 Técnicas de muestreo estadístico
Técnica de muestreo Descripción
Número aleatorio Los elementos se seleccionan al azar de una población para que cada
Muestreo el artículo tiene las mismas posibilidades de ser seleccionado.
Muestreo sistemático Un método de muestreo aleatorio que comienza la muestra por

(Muestreo de intervalo) seleccionar un punto de partida aleatorio en una población y luego
seleccionando los elementos restantes a intervalos fijos. Este método
no debe utilizarse para la selección de una población que tiene un
patrón fijo.
Muestreo estratificado Un método de muestreo aleatorio que separa la población

en grupos homogéneos antes de seleccionar una muestra aleatoria.
Este método debe utilizarse para la selección de una población.
con amplias variaciones de valor.
Muestreo de conglomerados (bloque Un método de muestreo aleatorio que separa la población

Muestreo) en grupos similares, y luego selecciona una muestra aleatoria de la
grupo.
Muestreo de parada o marcha Minimiza el tamaño de la muestra asumiendo una tasa de error baja. Eso
(Muestreo secuencial) estima la tasa de error de la población dentro de un determinado
intervalo (p. ej., número más o menos, etc.).
Muestreo de descubrimiento Comprueba si hay errores o irregularidades importantes. No debería ser usado
donde existen condiciones desviadas conocidas.
Muestreo por unidad de dólar Este método utiliza el dólar como unidad de muestreo, que aumenta
(Probabilidad proporcional la probabilidad de que se seleccionen valores en dólares mayores. Eso
medir) detecta principalmente pagos en exceso.
Media por unidad El valor medio de una muestra se calcula y se multiplica por el
unidades en la población para estimar el valor total de la
población.
Estimación de diferencias La diferencia promedio entre el valor de auditoría y el valor en libros.

para una unidad de muestra se calcula. Esta diferencia es entonces
multiplicado por la población para estimar el valor total.
Estimación de razón La relación de la muestra al valor contable se multiplica por la población

valor contable para estimar el valor total.
Fuente: De Senft, S., Gallegos, F. y Davis, A. (2012). Control de tecnología de la información y

Auditoría . CRC Press / Taylor & Francis, Boca Raton, FL.
Página 141
CAAT para revisiones de aplicaciones

Existe una variedad de CAAT que son útiles para auditar aplicaciones e integridad de datos. Un
ejemplo de tales técnicas incluye software de auditoría generalizado. El software de auditoría generalizado puede
ser utilizado para analizar la lógica y los cálculos de la hoja de cálculo para verificar su precisión e integridad, evaluar los da
producidos a partir de aplicaciones (que residen en bases de datos), y producen diagramas de flujo de datos lógicos, entre
otros. Al auditar bases de datos, por ejemplo, las técnicas relacionadas con la minería de datos pueden buscar "a través de
grandes cantidades de datos computarizados para encontrar patrones o tendencias útiles ". * Técnicas de minería de datos
ayudar a analizar datos desde diferentes perspectivas y resumirlos en información útil.
Otro ejemplo relacionado incluye el análisis de datos (DA) o procedimientos para examinar datos sin procesar en orden
para sacar conclusiones. La DA se utiliza en muchas industrias para permitir una mejor toma de decisiones, y en ciencia
cia para verificar o refutar modelos o teorías existentes. † DA se diferencia de la minería de datos por el
alcance, propósito y enfoque del análisis. La minería de datos clasifica grandes cantidades de datos utilizando
software sofisticado para identificar patrones no descubiertos y establecer relaciones ocultas
buques. DA, por otro lado, se centra en el proceso de derivar una conclusión (o inferir) basada
únicamente en lo que ya se sabe.
El software de auditoría generalizado permite realizar las funciones necesarias directamente en la aplicación.
archivos de cation, ya que utiliza especificaciones proporcionadas por el auditor para generar un programa que realiza
funciones. Los auditores financieros, por ejemplo, utilizan software de auditoría generalizado para:
◾ Analizar y comparar archivos

◾ Seleccionar registros específicos para su examen
◾ Realizar muestras aleatorias
◾ Validar cálculos
◾ Preparar cartas de confirmación
◾ Analizar la antigüedad de los archivos de transacciones
Los auditores de TI también utilizan estas técnicas de software para probar y / o documentación de programas seleccionados
ceses dentro del entorno de TI en forma de diagramas de flujo y diagramas de flujo de datos, por ejemplo.
El software de auditoría generalizado permite a los auditores de TI evaluar los controles de la aplicación, así como realizar c
analizar datos computarizados para pruebas de auditoría sustantivas, entre otros. Algunos de los mas populares
Los paquetes de software incluyen Audit Analytics de Arbutus Software, TopCAATs, CaseWare Analytics
Análisis de datos IDEA, Easy2Analyse, TeamMate y ACL. Todos estos son virtualmente similares en
en lo que respecta a la funcionalidad. El paquete de software ACL se describe a continuación como un ejemplo de lo que
estas técnicas pueden hacer.
Lenguaje de comandos de auditoría (ACL)
ACL es un software de auditoría general que lee de la mayoría de formatos (p. Ej., Bases de datos, archivos delimitados, tex
archivos, archivos de Excel, etc.) y proporciona selección, análisis e informes de datos. Más específicamente, ACL
es una herramienta de interrogación de archivos diseñada para ayudar en la auditoría de aplicaciones, ya que puede manejar
grandes cantidades de datos. Las funciones de ACL varían desde: (1) identificación de negativo, mínimo y máximo
saldos de mamá; (2) realizar muestreos estadísticos y análisis de envejecimiento; (3) identificación de duplicados
* www.merriam-webster.com/dictionary/data%20mining.
† http://searchdatamanagement.techtarget.com/definition/data-analytics.
Página 142
o lagunas en la secuencia de pruebas; y (4) realizar uniones y emparejamientos comparativos; entre otros.
Los beneficios dentro de ACL incluyen:
◾ Visión general eficaz del formato y la estructura de un archivo

◾ Capacidad para importar varios tipos de archivos de datos sin procesar
◾ Creación sencilla de muestras de auditoría y resúmenes
◾ Mayor cobertura de pruebas y mayor eficiencia
◾ Scripts que se pueden ejecutar en períodos actuales y posteriores
◾ Cuadros de diálogo para usar en aplicaciones interactivas
◾ Mayor comprensión de procesos y sistemas de entornos complejos
◾ Procedimientos manuales reducidos
Algunas de las características comunes de ACL incluyen:
◾ Definir e importar datos en ACL . Definir qué tipo de organización o datos del cliente
ser utilizado con fines de análisis de ACL es uno de los pasos más importantes al utilizar ACL. Aquí,
el auditor necesita identificar dos cosas: primero, la ubicación de los datos que se utilizarán; segundo, el
formato y estructura de dichos datos. Para evitar problemas al acceder a los datos o
acceder a las unidades protegidas por error, etc., es una buena práctica que el auditor pregunte a la organización
personal del cliente para colocar los datos requeridos para el análisis en una unidad separada (por ejemplo, audi-
memoria USB, CD, disco duro independiente, etc.). ACL tiene la capacidad de leer e importar datos
de archivos de retorno de carro (CR) (informes de texto sin formato donde los CR marcan el final de cada registro);
bases de datos, como dBASE, DB2 y Open Database Connectivity (ODBC) (por ejemplo, MS Access,
MS Excel, Oracle, etc.); archivos planos (datos ordenados secuencialmente en filas); y archivos delimitados (campos
separados por una coma, un punto y coma, etc.). Otros tipos de archivos leídos por ACL incluyen archivos de informe
archivos segmentados, archivos de longitud variable, archivos CR / Line Feed (LF), fuentes de datos con o sin archiv
diseño, archivos de longitud fija, archivos LF, bases de datos de mainframe y archivos de tipo de registro múltiple.
◾ Personalizar una vista . Con ACL, el auditor puede modificar la vista del archivo original que se
definido en uno que se adapte mejor al análisis de datos en cuestión. ACL también permite la audición
tor para crear una nueva vista o cambiar las existentes sin "tocar" los datos reales de
el archivo. Esto significa que los cambios en la visualización de los datos son solo para fines de presentación y
por lo tanto, no modificaría ni eliminaría los datos.
◾ Filtrado de datos . Los filtros se crean fácilmente en ACL y son útiles para un análisis y control rápidos
totales una vez que se importa un archivo. El filtrado de datos a través de ACL permite a los auditores respaldar sus p
y análisis. El filtrado en ACL utiliza operadores lógicos (por ejemplo, Y, O, NO, etc.) como condiciones
para generar de manera efectiva información que coincida con un criterio específico. Por ejemplo, los auditores puede
para
para asientos
que dichadeinformación
diario contables específicos
basada publicados
en condiciones en un día
se produzca festivo
para o fueraHay
su análisis. de horas. ACL
dos tipos depermitiría
filtros:
filtros globales y filtros de comando. Un filtro global, cuando se activa, se aplica a todos los comandos y
a todas las vistas de la tabla activa. Los filtros globales permanecen en su lugar hasta que se quitan o hasta que la mes
cerrado. Un filtro de comando, por otro lado, se aplica a un solo comando y permanece en efecto
solo hasta que ACL procese el comando. Los filtros se pueden nombrar, guardar y reutilizar cuando sea necesario.
◾ Análisis de datos . Los auditores utilizan ACL para evaluar y transformar datos en información utilizable.
Los datos pueden ser de cualquier tamaño, formato y desde casi cualquier plataforma. Tanto analítico como lógico
El razonamiento se utiliza para examinar cada componente de los datos y extraer el significado incluso de
cantidades significativas de datos. Los comandos de ACL en la figura 4.9 se usan comúnmente para
realizar tareas de análisis de datos.
Página 143
Figura 4.9 Comandos de ACL que se usan comúnmente al realizar análisis de datos
Comando ACL Descripción
Extraer Selecciona registros o campos de un archivo o tabla actual y los copia a una
archivo o tabla diferente.
Exportar Envía datos a un archivo externo (por ejemplo, base de datos, Excel, archivo de texto, etc.) para su uso
fuera de ACL.
Clasificación Ordena u organiza la tabla activa en orden ascendente o descendente

basado en campos clave especificados.
Verificar Comprueba si hay errores de validez de datos en la tabla activa. Asegura que los datos en un
la tabla se ajusta al diseño de la tabla e informa sobre los errores encontrados.
Buscar Ubica el primer registro en una tabla indexada que cumple con un criterio específico /
condición.
Adjuntar Agrega la salida del comando al final de un archivo existente en lugar de sobrescribir
el archivo existente.
Contar Totaliza el número de registros en la tabla actual, o solo esos registros

que cumplen con un criterio o condición de prueba especificados.
Total Suma campos numéricos o expresiones en la tabla activa.
Estadístico Se utiliza en campos numéricos y de fecha para obtener una descripción general de los datos. los
El comando estadístico produce (1) recuentos de registros, totales de campo y promedio
valores de campo para valores de campo positivos, nulos y negativos; (2) absoluto
valores; (3) rangos; y (4) valores de campo más altos y más bajos.
Estratificar Permite ver una distribución de registros que caen en intervalos específicos.
o estratos. Es decir, cuenta la cantidad de registros que caen en
intervalos de valores de expresión o campo numérico, y subtotales uno o más
campos para cada estrato.
Clasificar Cuenta el número de registros relacionados con cada valor único de un carácter
campo y subtotales campos numéricos especificados para cada uno de estos
valores.
Histograma Proporciona una descripción general del contenido de una tabla. Específicamente, produce un 3-D
gráfico de barras verticales de la distribución de registros sobre los valores de un campo
o expresión.
Años Produce resúmenes de datos antiguos (p. Ej., Clasificación de
facturas)
Resumir Genera un recuento de registros y totales de valor de campo numérico para cada
valor de los campos de caracteres clave en una tabla ordenada.
Examinar Determina si los campos clave de la tabla activa están en orden secuencial,
Secuencia y detecta espacios, duplicados o números faltantes en la secuencia.
Busque huecos Detecta espacios en los campos clave de la tabla actual (p. Ej., Espacios en números,
fechas, etc.)
( Continuacion )
Página 144
Figura 4.9 ( continuación ) Comandos de ACL que se utilizan comúnmente en la realización de análisis de datos
Comando ACL Descripción
Buscar Detecta si los campos clave de la tabla actual contienen duplicados en el

Duplicados secuencia.
Muestreo ACL ofrece muchos métodos de muestreo para análisis estadístico. Dos de los mas
utilizados con frecuencia son el muestreo por registros (RS) y el muestreo por unidad monetaria
(MUS), ambos creados a partir de una población dentro de una tabla. Cada método permite
muestreo aleatorio y por intervalos. MUS extrae registros de muestra de datos
conjunto. MUS se usa normalmente si el archivo está muy sesgado con un valor grande
artículos. RS, por otro lado, trata cada registro por igual, utilizando un valor nominal
valor de uno. RS se utiliza cuando los registros de un archivo se distribuyen de manera bastante uniforme
a través de los datos, lo que da como resultado que cada registro tenga la misma probabilidad de ser
seleccionado. La elección de los métodos dependerá del muestreo general
propósito, así como la composición del archivo que se audita.
Al planificar un proyecto de análisis de datos de ACL, es importante que los auditores de TI sigan los pasos
abajo:
◾ Paso 1: Adquirir los datos

◾ Paso 2: Acceder a los datos
◾ Paso 3: Verificación de la integridad de los datos
◾ Paso 4: Analizar y probar los datos
◾ Paso 5: Informar los hallazgos
Paso 1: Adquirir los datos

El auditor debe conocer los datos que necesita para cumplir con los objetivos del proyecto especificado.
Para ello, el auditor debe reunir la información necesaria reuniéndose con diversas organizaciones.
personal de cliente y / o cliente, incluidos, entre otros, TI, MIS y / o contabilidad o finanzas
personal para comprender los datos, su tamaño, formato, estructura y campos de datos requeridos.
Paso 2: acceder a los datos

El auditor debe familiarizarse con los datos con los que está a punto de trabajar, en particular,
el archivo donde se almacenan los datos, la estructura del archivo, formato, diseño, tamaño, campos de datos, número de
registros, etc. El auditor debe evaluar los datos incluidos en el archivo para determinar qué
Se debe utilizar la tarea de análisis de datos y qué plataforma o entorno.
Paso 3: verificar la integridad de los datos

El auditor debe asegurarse de que los datos sean buenos. En otras palabras, los datos que se van a analizar
debe ser válido, exacto y completo, especialmente cuando se trabaja con archivos de datos que no
organizado en registros. ACL proporciona herramientas como contar, totalizar y verificar para hacer frente a estos tipos
de archivos de datos.
Página 145
Paso 4: Analizar y probar los datos

Los datos que se analizarán y probarán pueden ser de cualquier tamaño, formato y desde casi cualquier plataforma. Auditore
utilizar ACL para evaluar y transformar dichos datos en información significativa que pueda ayudar a sus
proceso de toma de decisiones. Hay varios comandos de ACL que se utilizan comúnmente al realizar
realizar estos tipos de análisis y pruebas de datos (consulte el Cuadro 4.9). El Apéndice 4 también muestra las mejores práct
procedimientos de auditoría cuando se usa ACL para realizar, por ejemplo, pruebas en asientos de diario de contabilidad.
Paso 5: Informar los hallazgos

Al completar la realización de análisis y pruebas de datos, los auditores de TI deben presentar y comunicar
sus resultados y hallazgos en un formato de fácil lectura. Como parte de informar los resultados, los auditores
debe mantener diseños de archivos y proyectos de ACL para fines de respaldo y para permitir la recreación, si es necesario
sary. Los auditores deben incluir información relacionada con ACL en los papeles de trabajo de auditoría, incluyendo, pero n
limitado a, copia del programa ACL, registros de ACL / diseños de archivo y solicitudes de datos para auditorías de años fut
CAAT para auditar controles de aplicaciones

Al auditar los controles de la aplicación, los auditores examinan los controles de entrada, procesamiento y salida específicos
a la aplicación. Los controles de aplicaciones también se denominan "controles automatizados". Entrada automatizada
Los controles validan los datos ingresados en el sistema y minimizan las posibilidades de errores y omisiones.
Los ejemplos de controles de entrada incluyen la comprobación de: caracteres en un campo; apropiado positivo / negativo
señales; importes contra valores fijos / limitados; importes contra los límites superior e inferior; tamaño de datos; y
integridad de los datos, entre otros. Los controles de procesamiento son aquellos controles que previenen, detectan y / o
corregir errores durante el procesamiento. Ejemplos de controles de procesamiento incluyen datos coincidentes antes de acci
tener lugar (por ejemplo, igualar el monto de la factura con la orden de compra y el informe de recepción, etc.), recalcular
establecer totales de lote, datos cruzados para verificar la precisión de los cálculos y garantizar que solo
se utilizan archivos correctos y más actualizados. Los controles de salida detectan errores después de que se completa el pro
Ejemplos de controles de salida incluyen la realización de conciliaciones de datos de informes (por ejemplo, libro mayor con
libros de contabilidad subsidiarios, etc.), revisando los informes para verificar su exactitud e integridad (por ejemplo, realiza
hijos del campo de datos clave, verificaciones de información faltante, etc.), y proteger la transferencia de datos a
asegurarse de que los datos se transmitan completa y adecuadamente (por ejemplo, cifrado, etc.).
Los CAAT son muy útiles para el auditor cuando evalúa los controles de aplicación relacionados con
procesamiento de transacciones. Como se describió anteriormente, los controles relacionados con el procesamiento de transa
se preocupan por la exactitud, integridad, validez y autorización de los datos capturados,
ingresado, procesado, almacenado, transmitido y reportado. Los auditores suelen trabajar con la organización
o hojas de cálculo y / o bases de datos proporcionadas por el cliente al realizar sus procedimientos. Solicitud
Los controles que se encuentran en hojas de cálculo y / o bases de datos que los auditores suelen probar incluyen
verificar la precisión matemática de los registros, validar la entrada de datos y realizar operaciones numéricas
controles de secuencia, entre otros. Los auditores deben asegurarse de que estos tipos de controles se implementen de maner
mentado para garantizar resultados precisos.
Controles de hoja de cálculo

Las hojas de cálculo pueden parecer relativamente sencillas debido a su uso generalizado. Sin embargo,
los riesgos presentados son significativos si se confía en los resultados de la hoja de cálculo para la toma de decisiones.
Página 146
La falta de confiabilidad, la falta de auditabilidad y la falta de modificabilidad son todos los riesgos asociados con
diseño deficiente de la hoja de cálculo. Los auditores utilizan CAAT para evaluar la distribución preparada por el cliente o la
hojas para analizar sus datos y finalmente formar opiniones. Deben implementarse controles
para minimizar el riesgo de datos incorrectos y lógica incorrecta, especialmente, si se reutilizan las hojas de cálculo. Alguno
de los controles clave que minimizan los riesgos en el desarrollo y uso de hojas de cálculo incluyen:
◾ Análisis. Comprender los requisitos antes de crear la hoja de cálculo

◾ Fuente de datos. Garantías de que los datos que se utilizan son válidos, fiables y pueden autenticarse
a la fuente de origen
◾ Revisión de diseño. Revisiones realizadas por pares o profesionales del sistema
◾ Documentación. Las fórmulas, los comandos de macro y cualquier cambio en la hoja de cálculo deben ser
documentado externamente y dentro de la hoja de cálculo
◾ Verificación de lógica. Verificaciones de razonabilidad y comparaciones con resultados conocidos
◾ Alcance de la formación. Capacitación formal en diseño, prueba e implementación de hojas de cálculo
◾ Alcance de la auditoría. Revisiones informales de diseño o procedimientos formales de auditoría
◾ Compromiso de apoyo. Mantenimiento continuo de aplicaciones y soporte del personal de TI
Controles de base de datos

Las bases de datos del departamento deben estar protegidas con controles que eviten cambios no autorizados en
los datos. Además, una vez que se implementa la base de datos, debe mantenerse en un programa separado
directorio y limitado a "ejecutar solamente". La base de datos también se puede proteger habilitando "read-
sólo ”capacidades de los usuarios para los datos que permanecen estáticos. Los derechos de acceso deben asignarse a
usuarios para tablas específicas (grupos de acceso). Las pantallas de entrada deben incluir controles de edición que
limitar la entrada de datos a opciones válidas. Esto se puede lograr teniendo una tabla de valores aceptables.
para los campos de datos. La precisión de los datos también se puede mejorar limitando el número de campos de forma libre
y proporcionar códigos de entrada clave con valores de búsqueda para la descripción completa. Controla que audi-
tors comúnmente esperan identificar (y en última instancia evaluar) dentro del cliente o la organización preparada
las bases de datos incluyen:
◾ Integridad referencial. Evitar eliminar valores clave de tablas relacionadas

◾ Integridad de la transacción. Restaurar el valor de las transacciones fallidas
◾ Integridad de la entidad. Cree una identificación de registro única
◾ Restricciones de valor. Limitar valores a un rango seleccionado
◾ Protección de actualización concurrente. Evitar la contención de datos
◾ Protección de respaldo
restaurar para y recuperación. Capacidad para realizar copias de seguridad de información y aplicaciones crít
continuar
◾ Prueba de protección. Realizar pruebas a nivel de sistemas, aplicaciones y unidades.
CAAT para revisiones operativas

Anteriormente, cubrimos una serie de técnicas utilizadas para realizar tareas para respaldar la auditoría de
aplicaciones. La mayoría de estas técnicas se pueden utilizar para respaldar las revisiones operativas, así como
Brindar información sobre la efectividad de los controles generales sobre las operaciones de TI. Sin embargo, el uso
de técnicas no necesita limitarse a paquetes especializados. Los lenguajes informáticos pueden ser útiles en
Página 147
realizar pruebas operativas y recopilar información sobre la eficacia de los controles generales.
Incluso las herramientas básicas como Access en MS Office se pueden utilizar para tomar un archivo de datos
datos nacionales (p. ej., información de cuenta de los usuarios y accesos a archivos, derechos sobre el número de accesos a a
etc.), realice análisis en el archivo (histogramas, frecuencias, resúmenes) y luego mueva los datos a
MS Excel y representar visualmente información para la gestión o incluso pronosticar tendencias con respecto a
carga de trabajo, crecimiento y otras áreas operativas de TI.
El enfoque de una revisión operativa es la evaluación de la eficacia, la eficiencia y el objetivo.
logro relacionado con las operaciones de gestión de sistemas de información. Pasos básicos de auditoría en una operación
Las revisiones técnicas son similares a las auditorías de TI o las auditorías de estados financieros, excepto por el alcance. Es
Las actividades en una revisión operativa incluyen:
◾ Revisar las políticas operativas y la documentación.

◾ Confirmar procedimientos con personal gerencial y operativo
◾ Observe las funciones y actividades operativas
◾ Examinar planes e informes financieros y operativos
◾ Pruebe la precisión de la información operativa
◾ Probar controles operativos
Auditoría en la computadora versus auditoría

A través de la computadora
Puede haber situaciones en el entorno de TI en las que la auditoría alrededor de la computadora o "caja negra
enfoque de auditoría ”puede ser más adecuado que auditar a través de la computadora cuando está automatizado
las aplicaciones son relativamente simples y directas. Al realizar auditorías alrededor de la empresa
computadora , el auditor obtiene documentos fuente que están asociados con transacciones de entrada particulares
y los reconcilia con los resultados de salida. Por lo tanto, la documentación de respaldo de la auditoría se elabora y
se llegan a conclusiones sin considerar cómo se procesan los insumos para proporcionar resultados.
Desafortunadamente, SAS No. 94 no elimina el uso de esta técnica. La mayor debilidad de
La auditoría en torno al enfoque informático es que no verifica ni valida si el pro-
La lógica gramatical de la aplicación que se está probando es correcta. Esto es característico de la auditoría mediante
el enfoque informático (o el "enfoque de auditoría de caja blanca").
El enfoque de auditoría a través de la computadora incluye una variedad de técnicas para evaluar cómo
la aplicación y sus controles integrados responden a varios tipos de transacciones (anoma-
mentiras) que pueden contener errores. Cuando las auditorías implican el uso de tecnologías avanzadas o complejas
aplicaciones, el auditor de TI debe recurrir a técnicas combinadas con herramientas para
probar y evaluar la aplicación. Este enfoque de auditoría es relevante dada la importancia de la tecnología
aumentar y su impacto en el proceso de auditoría. Las técnicas más utilizadas incluyen
instalación de prueba integrada, datos de prueba, simulación en paralelo, módulo de auditoría integrado, control de sistemas
archivo de revisión de auditoría (bufanda) y etiquetado de transacciones. Nuevamente, muchas de estas técnicas deben ser
integrado en la aplicación para que lo utilicen los auditores y el personal de seguridad de la información. Estas
técnicas proporcionan auditoría y evaluación continuas de la aplicación o sistemas y pro-
la gestión de vídeo y el personal de auditoría o seguridad, garantías de que los controles funcionan como
planeado, diseñado e implementado. Estos se describen, con sus ventajas y desventajas.
tages, en el cuadro 4.10.
Página 148
Figura 4.10 Técnicas de auditoría asistidas por computadora para programas de computadora
Auditoría
Técnica Descripción
Integrado Las instalaciones de prueba integradas son entornos de prueba incorporados dentro de un Diseñado en la aplicac
Prueba sistema. Este enfoque se utiliza principalmente con gran escala, en línea desarrollo. (UN)
Instalaciones sistemas que sirven a múltiples ubicaciones dentro de la empresa o Se requiere experienci
organización. La instalación de prueba está compuesta por una empresa ficticia (entornos de prueba
o rama, configurada en la aplicación y la estructura del archivo para aceptar o y garantizar que las t
Procesar transacciones de prueba como si fuera una operación real Información actual. (
entidad. A lo largo del ejercicio económico, los auditores pueden presentar Dado que el módulo d
transacciones para probar el sistema. o aplicación del clien
es alto. Los controles
implementado para i
probar transacciones
Datos de prueba Esta técnica implica métodos para proporcionar transacciones de prueba a un Se requiere experienci
sistema de procesamiento por aplicaciones existentes. Los datos de prueba proporcionan una Técnicas (UN)
espectro completo de transacciones para probar los procesos dentro del El riesgo de interrump
aplicación y sistema. Tanto las transacciones válidas como las inválidas deben mínimo debido al he
incluirse en los datos de prueba, ya que el objetivo es probar cómo se utiliza la aplicació
El sistema procesa entradas de transacciones tanto correctas como erróneas. Personal de la organiz
Para un servicio de tarjeta de crédito al consumidor, dichas transacciones pueden proporciona una cop
números de cuenta no válidos, cuentas suspendidas o Será difícil determin
eliminado y otros. Si se confía en el programa, la aplicación, exacto, reduciendo a
o pruebas del sistema, es esencial alguna forma de prueba intermitente. método. (RE)
Los generadores de datos de prueba son muy buenas herramientas para respaldar esta técnica.
pero no se debe confiar completamente en él para pruebas en condiciones extremas.
Página 149
Figura 4.10 ( continuación ) Técnicas de auditoría asistidas por computadora para programas de computadora
Auditoría
Paralelo La simulación paralela implica el mantenimiento por separado de dos El riesgo de interrump
Simulación presumiblemente conjuntos de programas idénticos. El conjunto original de mínimo. La simulaci
programas es la copia de producción utilizada en la aplicación bajo El auditor obtiene info
examen. El segundo conjunto podría ser una copia asegurada por auditores. intervención de la or
al mismo tiempo que la versión original se colocó en (UN)
producción. A medida que se realizan cambios o modificaciones en el La medida en que se r
programas de producción, los auditores realizan las mismas actualizaciones a sus sobre la complejidad
copias. Si no se ha realizado ninguna alteración no autorizada, utilice el procesamiento siend
mismas entradas, comparando los resultados de cada conjunto de programas
debería producir los mismos resultados. Otra forma es que el auditor
Desarrollar pseudocódigo utilizando lenguajes de nivel superior (Vbasic, SQL,
JAVA, etc.) de la documentación base siguiendo el proceso
lógica y requisitos. Para fines de auditoría, tanto el software
aplicaciones (prueba versus real) utilizarían las mismas entradas y
generar resultados independientes que se puedan comparar para validar la
Pasos de procesamiento interno.
Incrustado Módulo de auditoría programado que se agrega a la aplicación en El módulo integrado p

Auditoría revisión. y recopilar datos par
Módulo riesgos y eficacia. (U
El nivel de experienci
alto, ya que los audit
programación para d
módulo. (RE)
El riesgo de interrump
todas las transaccion
algoritmo de cribado
velocidad de procesa
Página 150
Figura 4.10 ( continuación ) Técnicas de auditoría asistidas por computadora para programas de computadora
Auditoría
Sistemas El archivo de revisión de auditoría de control de sistemas (SCARF) es otro Permitir que los audito
Controlar técnica que puede recopilar transacciones o procesos específicos que sistema de aplicación
Auditoría violar ciertas condiciones o patrones predeterminados. Esto podría ser les interesan. (UN)
revisión mejorado por el software de soporte de decisiones que alerta designado Se requiere experienci
Archivo personal (auditoría, seguridad, etc.) de actividad inusual o elementos fuera de un sistema de aplicac
(BUFANDA) lo ordinario. Los especialistas en informática forense pueden recopilar datos para registrar no afectan a los dato
archivos para revisión y examen adicionales. El riesgo de interrump
Los controles deben
implementado para i
las rutinas de auditor
Transacción Sigue una transacción seleccionada a través de la aplicación desde la entrada, Etiqueta las transaccio
Etiquetado transmisión, procesamiento y almacenamiento a su salida para verificar la Permite a los auditore
integridad, validez y confiabilidad de la aplicación. Algunos instantánea de activi
Las aplicaciones tienen una función de seguimiento o depuración, que puede permitir Experiencia requerida
para seguir la transacción a través de la aplicación. Esto puede ser un etiqueta) al registro d
manera de asegurar que el proceso para manejar transacciones inusuales sea El riesgo de interrump
seguido dentro de los módulos y el código de la aplicación. alto. Los controles d
implementado para i
designación especial
evaluado. (RE)
Fuente: De Senft, S., Gallegos, F. y Davis, A. (2012). Control y Auditoría de Tecnologías de la Información . CRC Press / Taylor & Francis, Boc
Página 151
Herramientas de informática forense

La informática forense es el examen, análisis, prueba y evaluación de material informático.
rial realizado para proporcionar información relevante y válida a un tribunal de justicia. Informática forense
Las herramientas se utilizan cada vez más para respaldar la aplicación de la ley, la seguridad informática y la auditoría inform
investigaciones.
Una buena fuente para evaluar las herramientas de informática forense es la prueba de herramientas de informática foren
(CFTT) Sitio web del proyecto en www.cftt.nist.gov/. CFTT es un proyecto conjunto del NIST, EE. UU.
Instituto Nacional de Justicia (NIJ) del Departamento de Justicia, Oficina Federal de Investigaciones
(FBI), el Laboratorio de Defensa Informática Forense (DCFL), el Servicio de Aduanas de EE. UU. Y otros
ers para desarrollar programas para probar herramientas informáticas forenses utilizadas en la investigación de delitos
involucrando computadoras.
Una herramienta recientemente revisada por CFTT fue EnCase Forensics de Guidance Software, Inc.
EnCase habilita investigaciones forenses informáticas “no invasivas”, lo que permite a los examinadores ver
archivos evant, incluidos los archivos "eliminados", la holgura del archivo y el espacio no asignado. Otros recursos valiosos
para la experiencia en el uso de herramientas informáticas forenses serían aquellas asociaciones profesionales o
organizaciones que apoyan esta área. Algunos de ellos serían The International High Technology
Asociación de Investigadores del Crimen, Asociación de Examinadores Certificados de Fraude, Instituto de
Auditores internos, Grupo de trabajo sobre delitos electrónicos del gobierno federal, Computadora regional del FBI
Laboratorio Forense y Coloquio de Educación en Seguridad de los Sistemas de Información. Nota
que al aplicar herramientas informáticas forenses, se debe conocer la metodología investigativa,
procesos y procedimientos que deben seguirse para garantizar que la evidencia se pueda recopilar con éxito
minuciosamente, documentado y no contaminado como material probatorio que pueda ser utilizado en la corte. Un
excelente recurso aquí es la publicación del Departamento de Justicia de EE. UU., Prosecuting Computer Crimes
(2a edición) publicada en 2010, así como información proporcionada por High Tech Criminal
Asociación de Investigación (www.htcia.org).
Conclusión
La continua evolución de la TI ha puesto las funciones avanzadas (software) en manos de los auditores de TI
para postularse en apoyo de la conducción, documentación y ejecución del proceso de auditoría. Estos software
Las herramientas y técnicas permiten al auditor aplicar enfoques innovadores para validar procesos en
el nivel de aplicaciones.
Las herramientas de productividad del auditor, por ejemplo, incluyen software para automatizar la función de auditoría y
integrar la información recopilada como parte del proceso de auditoría. Estas herramientas permiten a los auditores reducir
la cantidad de tiempo dedicado a tareas administrativas. Las técnicas de documentación del sistema también son
muy común, y se utilizan principalmente para documentar y probar sistemas de aplicación, procesos de TI y
su integración en el entorno de TI. Diagramas de flujo, diagrama de flujo de datos y procesos comerciales
Los diagramas son buenos ejemplos de técnicas de documentación del sistema. Por último, los CAAT ayudan a los auditores
al evaluar los controles de la aplicación, y seleccionar y analizar datos computarizados para
pruebas de auditoría.
Los CAAT pueden ser utilizados por auditores financieros y / o de TI, de diversas formas, para definir muestras
medir y seleccionar muestras, determinar el cumplimiento de los procedimientos y monitorear
cesando resultados. Los auditores de TI, por ejemplo, utilizan CAAT para revisar aplicaciones con el fin de obtener una
Comprensión de los controles establecidos para garantizar la precisión e integridad de la información.
generado.
Página 152
Los auditores utilizan software de auditoría generalizado (un tipo de CAAT) para evaluar la integridad de las aplicacion
cationes. El software de auditoría generalizado permite a los auditores analizar y comparar archivos, seleccionar archivos esp
registros para examen, realizar muestras aleatorias, validar cálculos, preparar confirmación
cartas, y analizar la antigüedad de los archivos de transacciones, entre otros. Algunos de los generalizados más populares
El software de auditoría incluye Audit Analytics de Arbutus Software, TopCAATs, CaseWare Analytics
Análisis de datos IDEA, Easy2Analyse, TeamMate y ACL. Todos estos son virtualmente similares en
en lo que respecta a la funcionalidad.
El paquete de software ACL, descrito en este capítulo, es una herramienta de interrogación de archivos diseñada para le
datos de la mayoría de los formatos (por ejemplo, bases de datos, archivos delimitados, archivos de texto, archivos de Excel
selección, análisis e informes de datos. ACL maneja y procesa grandes cantidades de datos para
identificar los saldos negativos, mínimos y máximos; realizar muestreo estadístico y análisis de envejecimiento
ses; identificar duplicados o lagunas en la secuencia de pruebas; y realizar uniones y combinaciones comparativas.
Los CAAT también se utilizan para realizar revisiones operativas y como herramienta informática forense.
Una revisión operativa se centra en la evaluación de la eficacia, la eficiencia y el logro de las metas.
relacionados con las operaciones de gestión de sistemas de información. Como herramienta forense informática, los auditore
Examinar, analizar, probar y evaluar material informático para proporcionar información relevante y
información válida a un tribunal de justicia. Las herramientas informáticas forenses se utilizan cada vez más para respaldar l
investigaciones de cumplimiento, seguridad informática y auditoría informática.
1. ¿Qué son las herramientas de productividad de auditoría? ¿Cómo ayudan a los auditores?
2. ¿Qué son los CAAT y qué beneficios brindan a los auditores de TI?
3. Describa las siguientes técnicas de documentación del sistema que se utilizan comúnmente para comprender
sistemas de aplicación financiera:
a. Diagramas de flujo de datos
segundo. Diagramas de procesos comerciales
C. Diagramas de flujo
4. Enumere los pasos necesarios en el desarrollo de diagramas de flujo.
5. Se sabe que los CAAT ayudan a los auditores a definir el tamaño de la muestra y seleccionar una muestra para la prueb
propósitos de ing. Describir dos técnicas utilizadas por los CAAT para definir el tamaño de la muestra y seleccionar e
muestra.
6. ¿Qué es el software de auditoría del lenguaje de comandos de auditoría (ACL)? Enumere los beneficios que brinda.
7. Explique los cuatro pasos a seguir al planificar un proyecto de análisis de datos de ACL.
8. Los controles de hoja de cálculo son un tipo de controles de aplicación que utilizan los auditores. Enumere y describa
cinco controles clave de la hoja de cálculo.
9. ¿Cuál es el énfasis o el enfoque de una revisión operativa? Enumere actividades específicas cuando
formando una revisión operativa.
10. ¿Qué es la informática forense? ¿Qué admiten las herramientas forenses informáticas? Cómo crees que
las herramientas informáticas forenses pueden ayudar al auditor de TI?
Ejercicios
1. Enumere y describa tres categorías amplias de funciones de auditoría informática que utilizan los profesionales de TI
para apoyar la auditoría de una aplicación. Explique su aplicación.
Página 153
2. Usted es un auditor senior de TI que tiene una reunión de planificación con sus dos miembros del personal. los
La tarea en cuestión es un proyecto de análisis de datos de ACL para el cliente. Enumere y describa los pasos que
y su equipo debe seguir para entregar un proyecto exitoso.
3. Diferenciar entre "auditar alrededor de la computadora" y "auditar a través de la computadora".
CASO: PROCESO DE GESTIÓN DEL CONTROL DE CAMBIOS
RESUMEN: Un proceso de gestión de control de cambios es un método que define formalmente,

evalúa y aprueba los cambios de la aplicación antes de su implementación en vivo o
Ambientes de conduccion. El proceso incluye varios procedimientos de control para asegurar que la implementación
Los cambios introducidos causarán un impacto mínimo en los objetivos de la organización. Estas
Los procedimientos incluyen la presentación de solicitudes de cambio, determinación de viabilidad, aprobación,
e implementación. A continuación se describen los roles y procedimientos típicos que se llevan a cabo en un
proceso de gestión del control de cambios.
ROL: SOLICITUD DE CAMBIO

El Solicitante de cambios identifica un requisito de cambio en la aplicación (por ejemplo, actualizaciones
a nuevas ediciones, etc.). Luego, el Solicitante prepara un Formulario de solicitud de cambio (CRF), que incluye
descripción del cambio, análisis de costos y beneficios, impacto, aprobaciones y cualquier otro
documentación de respaldo que se considere necesaria. Luego, envía el CRF al Proyecto
Gerente para revisión adicional.
ROL: GERENTE DE PROYECTO

Una vez recibido, el Gerente de Proyecto revisa el CRF y determina si
Se requiere información adicional para que la Junta de Control de Cambios evalúe el impacto total de la
cambio en términos de tiempo, alcance y costo (es decir, factibilidad). La decisión se basa entre otros
en factores, tales como:
◾ Número de opciones de cambio presentadas

◾ Viabilidad y beneficios del cambio
◾ Riesgos e impacto en la organización
◾ Complejidad y / o dificultad de las opciones de cambio solicitadas
◾ Escala de las soluciones de cambio propuestas
Si el Gerente de Proyecto determina que el cambio es factible, registrará el CRF en el

cambie el registro por número y rastree su estado. Luego, el Gerente de Proyecto envía el CRF
al tablero de control de cambios. Por otro lado, si el CRF no se considera factible, la
Project Manager cerrará el CRF.
PAPEL: CAMBIAR TABLERO DE CONTROL

Una vez recibido, la Junta de Control de Cambios revisa el CRF y cualquier documento de respaldo.
información proporcionada por el Project Manager. La placa de control de cambios representa un
organismo calificado que es en última instancia responsable de aprobar o rechazar los CRF en función de las
análisis (es decir, viabilidad).
Página 154
Después de una revisión formal, la Junta de Control de Cambios puede:
◾ Rechazar el cambio (las razones del rechazo se notifican de nuevo al Cambio

Solicitante)
◾ Solicite más información relacionada con el cambio
◾ Aprobar el cambio según lo solicitado o sujeto a condiciones específicas
Una vez aprobado, la Junta de Control de Cambios envía el cambio y cualquier soporte relacionado
documentación al equipo de implementación.
PAPEL: EQUIPO DE IMPLEMENTACIÓN

El equipo de implementación programa y prueba el cambio aprobado. Si los resultados de la prueba no son
correctamente, el cambio y toda la documentación de respaldo relacionada se devuelven para volver a probarlos.
Si los resultados son exitosos, el equipo de implementación implementa formalmente el cambio y
notifica al Solicitante de Cambio.
TAREA: Prepare un diagrama de flujo que describa el proceso de gestión del control de cambios que se acaba de describ
Asegúrese de segregar los roles (es decir, Solicitante de cambios, Gerente de proyectos, Control de cambios
Junta y Equipo de Implementación) en columnas verticales al crear el diagrama de flujo para ilustrar
tratar los procedimientos realizados en el proceso. Esta representación es útil para que los auditores
evaluar la segregación de funciones e identificar funciones incompatibles dentro del proceso.
Otras lecturas
1. AICPA. Análisis de auditoría y auditoría continua: mirando hacia el futuro, www.aicpa.org/
2. AICPA. (2007).
Principales Consideraciones
iniciativas de tecnología
tecnológicas. de Instituto
Nueva York: la información en lade
Americano auditoría basada
Contadores en riesgos:
Públicos una descripción
Certificados (AICPA). estratégica
3. Barbin, D. y Patzakis, J. (2002). Ciberdelincuencia y medicina forense. IS Control J. , 3, 25-27.
4. Bates, TJ (2000). Pruebas informáticas: problemas recientes. Inf. Segundo. Tech. Rep. , 5 (2), 15-22.
5. Braun, RL y Davis, HE (2003). Herramientas y técnicas de auditoría asistidas por computadora: análisis y
perspectivas. Gestionar. Auditoría. J. , 18 (9), 725–731. www.emeraldinsight.com/doi/full/10.1108/02686900310500488
6. Cerullo, VM y Cerullo, MJ (2003). Impacto de SAS No. 94 en las técnicas de auditoría informática. ES
Control J. , 1, 53–57.
7. Sitio web del proyecto Computer Forensic Tool Testing (CFTT), Instituto Nacional de Estándares y
Technology, www.cftt.nist.gov/ (consultado en marzo de 2017).
8. Deloitte, LLP (2014). ACL para auditores . Documento interno inédito.
9. Deloitte, LLP (2014). Documentos de trabajo de planificación de auditoría de TI . Documento interno inédito.
10. Diez consideraciones de TI clave de EY para la auditoría interna: evaluación de riesgos de TI y plan de auditoría efectivos.
ning. (Febrero de 2013). Información sobre gobernanza, riesgo y cumplimiento, www.ey.com/Publication/
vwLUAssets / Ten_key_IT_considerations_for_internal_audit / $ FILE / Ten_key_IT_considerations_
for_internal_audit.pdf
11. Gallegos, F. (2001). WebMetrics: Herramientas de auditoría asistidas por computadora , Serie de auditoría EDP, # 73-20-50,
Editores Auerbach, Boca Raton, FL, págs. 1-16.
12. Gallegos, F. (2002). Computadoras personales en auditoría de TI , auditoría de EDP, # 73-20-05, Auerbach
Publishers, Boca Raton, FL, págs. 1-7.
Página 155
13. Guidance Software, Inc., EnCase Enterprise, Pasadena, CA, www.guidancesoftware.com (se accede
Septiembre de 2016).
14. Heiser, J. y Kruse, W. (2002). Informática forense — Fundamentos de respuesta a incidentes , Addison-Wesley,
Reading, MA.
15. Conceptos básicos de auditoría de SI. El proceso de auditoría de los sistemas de información , www.isaca.org/knowledge-center/
itaf-is-assurance-audit- / pages / is-audit-basics.aspx (consultado en julio de 2017).
16. James, H. (2011). Auditoría de tecnologías de la información , tercera edición, South-Western Cengage Learning,
Nashville, TN.
17. Kaplin, J. (junio de 2007). Aproveche Internet . Auditor interno. Instituto de Auditores Internos, Lake
Mary, FL.
18. Kneer, DC (2003). Garantía continua: estamos muy atrasados. IS Control J. , 1, 30–34.
19. Laudon, KC y Laudon, JP (2014). Sistemas de información de gestión: gestión de lo digital
Firm , 13ª edición, Pearson, Upper Saddle River, Nueva Jersey.
20. McCafferty, J. (2016). Cinco pasos para planificar un programa de auditoría de TI eficaz . Instituto de Formación MIS,
6 (3), 841–849.
Nueva York.
27. Sarva, S. (2006). Auditoría continua mediante tecnología de apalancamiento. Inf. Syst. Assoc de Control de Auditoría.
J. , 2, 1–20.
28. Sayana, SA (2003). Uso de CAAT para respaldar la auditoría de SI. IS Control J. , 1, 21–23.
30. Singleton, T. (2006). Software de auditoría generalizada: herramienta eficaz y eficiente para las auditorías de TI actuales.
Inf. Syst. Assoc de Control de Auditoría. J. , 2, 1-3.
Página 157
156
PLANIFICACIÓN Y II
ORGANIZACIÓN
Página 159
158
Capítulo 5
Gobierno y estrategia de TI
1. Describa el gobierno de TI y explique la importancia de alinear la TI con los objetivos comerciales.
2. Describa los marcos de gobierno de TI relevantes.
3. Explicar la importancia de implementar métricas de desempeño de TI dentro de la organización.
en particular, el Cuadro de Mando Integral de TI. Describa los pasos para crear una TI equilibrada.
Cuadro de mando e ilustrar un ejemplo de apoyo.
4. Discutir la importancia del cumplimiento normativo y los controles internos en las organizaciones.
5. Definir la estrategia de TI y discutir el plan estratégico de TI y su importancia para alinear el negocio.
objetivos con TI.
6. Explique qué es un Comité Directivo de TI y describa sus tareas en una organización.
7. Discutir la importancia de la comunicación eficaz de la estrategia de TI a los miembros del
organización.
8. Describir los procesos de gobierno operativo y cómo controlan la entrega de proyectos de TI.
mientras se alinea con los objetivos comerciales.
El gobierno de TI ha adquirido mayor importancia en muchas organizaciones. Basado en la quinta versión

de Objetivos de Control para la Información y Tecnologías Relacionadas (COBIT), la gobernanza “asegura
que las necesidades, condiciones y opciones de las partes interesadas se evalúen para determinar
objetivos empresariales a alcanzar; establecer la dirección a través de la priorización y la toma de decisiones
En g; y monitorear el desempeño y el cumplimiento con respecto a la dirección y los objetivos acordados ". *
Con la globalización de muchas industrias y mercados financieros, desarrollados y en desarrollo
Las economías están reconociendo la importancia de una gobernanza y controles efectivos para el éxito
de organizaciones. La Ley Sarbanes-Oxley de 2002 (SOX) y el Comité de Patrocinio
Organizaciones de la Treadway Commission (COSO) (ambas de Estados Unidos), así como
el Código Combinado de Gobernanza en el Reino Unido y la Organización para
Los principios de cooperación y desarrollo de la gobernanza corporativa en Europa, todos, han establecido
barra de gobierno corporativo. Para TI, COBIT se ha convertido en el estándar global de gobernanza
y controles. COBIT proporciona un marco para implementar controles de TI para cumplir con SOX
* www.isaca.org/cobit/pages/default.aspx.
133
Página 160
y otros estándares de gobernanza global. Las organizaciones de todo el mundo están utilizando los principios
definido en COBIT para mejorar el desempeño de TI. Una estrategia es una visión formal para orientar en la
adquisición, asignación y gestión de recursos para cumplir con los objetivos de la organización. Un
La estrategia de TI, por ejemplo, es parte de la estrategia corporativa general para TI e incluye el futuro
dirección de la tecnología en el cumplimiento de los objetivos de la organización. El gobierno de TI proporciona
estructura y dirección para lograr la alineación de la estrategia de TI con la estrategia de negocio.
La estrecha alineación de la estrategia de TI con la estrategia empresarial es esencial para el éxito de un pozo
asociación en funcionamiento.
Gobierno de TI: alineación de TI con objetivos comerciales

En una encuesta realizada por el IT Governance Institute, el 94% de las organizaciones participantes consideraron
Consideraba que la TI era muy importante para la estrategia general de la organización. La misma encuesta señaló que el
Cuanto mayor sea el nivel de madurez del gobierno de TI, mayor será el retorno de la inversión en TI. Para lograrlo
La madurez de la gobernanza y un mayor retorno de la inversión en TI requieren una estrecha asociación entre
Gestión informática y empresarial. La estrecha alineación de la estrategia de TI con la estrategia comercial es
esencial para el éxito de una asociación que funcione bien. Es importante que la organización
comprender el negocio que apoya y que el negocio comprenda la tecnología que utiliza. por
Para que esto suceda, la organización debe tener un asiento en la mesa con el Director Ejecutivo
(CEO) y otros líderes empresariales.
Comunicarse con la alta dirección no es una tarea fácil ya que la TI es solo una pequeña parte
de los problemas que enfrentan las organizaciones en la actualidad. Los líderes de TI deben ser vistos como miembros valios
equipo, y no solo como proveedores de servicios. Para que esto suceda, el Director de Información (CIO)
y la gestión de TI debe buscar primero comprender los problemas comerciales y ofrecer soluciones proactivas
ciones a las necesidades de la organización. La administración de TI también debe tener una comprensión clara de sus
fortalezas y debilidades actuales y poder comunicar esta información a la empresa
administración.
El gobierno de TI proporciona la estructura para lograr la alineación de las actividades y procesos de TI
con los objetivos comerciales, incorporar TI en el programa de gestión de riesgos empresariales, administrar
el rendimiento de TI, garantizar la entrega de valor de TI y asegurarse del cumplimiento normativo
e implementación adecuada de controles internos.
La gestión eficaz de una organización requiere una base sólida de gobernanza y control.
sobre los recursos de TI. La gobernanza guía los derechos de decisión, la responsabilidad y los comportamientos de un
organización. Esto se controla mediante una serie de procesos y procedimientos que identifican quién
puede tomar decisiones, qué decisiones se pueden tomar, cómo se toman las decisiones, cómo se realizan las inversiones
administrado y cómo se miden los resultados. Implementado de manera efectiva, el gobierno de TI permite
que los vínculos y procesos estén alineados con la dirección marcada por el órgano de gobierno para lograr
objetivos empresariales.
La entrega de valor de TI es un esfuerzo conjunto entre la empresa y TI para desarrollar los requisitos adecuados.
y trabajar juntos para obtener con éxito los beneficios prometidos. Para ser eficaz, el
Junta Directiva (Junta), el órgano de gobierno de una organización que incluye el comité de auditoría para
a quien el director ejecutivo de auditoría puede informar funcionalmente, debe comprender el estado actual de TI
y participar activamente en el establecimiento de la dirección futura de TI.
Comunicarse eficazmente con la Junta sobre TI no siempre es fácil. Es un muy complejo
entorno, que es difícil de explicar a los profesionales que no son de TI. Además, muchos miembros
del Consejo o de la alta dirección tendrá sus propios problemas y un interés personal en determinados
Página 161
Gobierno y estrategia de TI ◾ 135
proyectos y servicios que puedan influir en el proceso de toma de decisiones. Conseguir un acuerdo por adelantado
en las medidas de desempeño de TI contribuirá en gran medida a enfocar a la alta gerencia en el
cuestiones clave en la gestión de TI. La medición del rendimiento empresarial y de TI también ayudará a mantener
Partes responsables del éxito de los proyectos de TI y la prestación de servicios.
Marcos de gobierno de TI
Entre los tres marcos relacionados con las mejores prácticas y ampliamente reconocidos se incluyen: Infraestructura de TI
Library (ITIL), COBIT y la British Standard International Organization for Standardization
(ISO) / Comisión Electrotécnica Internacional 27002 (ISO / IEC 27002). Estos tres marcos
Las obras brindan a las organizaciones los medios para abordar diferentes ángulos dentro del campo de la TI.
ITIL
ITIL fue desarrollado por la Oficina del Gabinete de Comercio Gubernamental (OGC) del Reino Unido
como una biblioteca de procesos de mejores prácticas para la gestión de servicios de TI. Ampliamente adoptado en todo el
mundial, ITIL proporciona pautas para las mejores prácticas en el campo de la gestión de servicios de TI. Específicamente,
El entorno de gestión de servicios de ITIL ofrece servicios empresariales de forma eficaz y eficiente a
usuarios finales y clientes siguiendo cinco directrices básicas relacionadas con:
◾ Estrategia: directrices o procesos de mejores prácticas para mapear la estrategia de TI con el negocio en general.
metas y objetivos.
◾ Diseño : procesos (o requisitos) de mejores prácticas implementados para guiar hacia una solución.
diseñado para satisfacer las necesidades comerciales.
◾ Transición: tiene como objetivo gestionar el cambio, el riesgo y la garantía de calidad durante la implementación.
de un servicio de TI.
◾ Operación: directrices o procesos de mejores prácticas implementados para mantener
servicios de TI eficaces una vez implementados en el entorno de producción.
◾ Mejora continua : busca constantemente formas de mejorar el proceso y el servicio en general.
provisión de vicio.
El marco ITIL debe elegirse cuando el objetivo de la organización es mejorar la calidad

idad de los servicios de gestión de TI. El marco ITIL ayuda a las organizaciones a crear servicios de TI
vicios que pueden ayudar eficazmente a gestionar las tareas diarias, especialmente cuando el foco está en
cliente o usuario final.
COBIT
COBIT es un marco de gobierno de TI que ayuda a las organizaciones a enfrentar los desafíos comerciales actuales.
en las áreas de cumplimiento normativo, gestión de riesgos y alineación de la estrategia de TI con
metas organizacionales. COBIT es un conjunto internacional autorizado de prácticas de TI generalmente aceptadas.
tices u objetivos de control, diseñados para ayudar a los empleados, gerentes, ejecutivos y auditores en:
comprender los sistemas de TI, cumplir con las responsabilidades fiduciarias y decidir los niveles adecuados de
seguridad y controles.
COBIT apoya la necesidad de investigar, desarrollar, publicitar y promover la internacionalización actualizada.
objetivos de control de TI totalmente aceptados. El énfasis principal del marco COBIT es asegurar
Página 162
que la tecnología proporciona a las empresas información relevante, oportuna y de calidad para tomar decisiones
haciendo propósitos.
El marco COBIT, ahora en su quinta edición (COBIT 5), permite a la gerencia comparar
marcar su entorno y compararlo con otras organizaciones. Los auditores de TI también pueden usar COBIT para
fundamentar sus evaluaciones y opiniones de control interno. Porque el marco es completo
En general, proporciona garantías de que existen controles y seguridad de TI.
COBIT 5 ayuda a las organizaciones a crear un valor óptimo de TI manteniendo un equilibrio entre
obteniendo beneficios y optimizando los niveles de riesgo y el uso de recursos. COBIT 5 se basa en cinco principios
principios (ver figura 3.2). COBIT 5 considera las necesidades de TI de las partes interesadas internas y externas
(Principio 1), al tiempo que cubre completamente el gobierno y la gestión de la información de la organización.
tecnología y tecnología relacionada (Principio 2). COBIT 5 proporciona un marco integrado que se alinea
y se integra fácilmente con otros marcos (por ejemplo, Comité de Organizaciones Patrocinadoras del
Treadway Commission-Enterprise Risk Management (COSO-ERM), etc.), estándares y mejores
prácticas utilizadas (Principio 3). COBIT 5 permite que la TI sea gobernada y administrada de una manera holística.
ner para toda la organización (Principio 4). Por último, COBIT 5 ayuda a las organizaciones a
separar la gobernanza de los objetivos de gestión (principio 5).
El marco es valioso para organizaciones de todos los tamaños, incluidas las comerciales, no para
lucro, o en el sector público. El marco integral proporciona un conjunto de objetivos de control
también auditores de TI en su búsqueda por examinar esos objetivos.
La selección de COBIT puede ser apropiada cuando el objetivo de la organización no es solo
comprender y alinear los objetivos comerciales y de TI, sino también abordar las áreas de cumplimiento normativo
gestión de riesgos y riesgos.
ISO / IEC 27002

El marco ISO / IEC 27002 es un estándar global (utilizado junto con ISO / IEC 27001
marco) que proporciona recomendaciones de mejores prácticas relacionadas con la gestión de la información
seguridad. La norma se aplica a los encargados de iniciar, implementar y / o mantener
Mantenimiento de sistemas de gestión de seguridad de la información. Este marco también ayuda a implementar
controles y procedimientos de seguridad de la información comúnmente aceptados.
La familia de normas ISO / IEC 27000 incluye técnicas que ayudan a las organizaciones a asegurar
sus activos de información. Algunos estándares, además del mencionado anteriormente, involucran a TI
técnicas de seguridad relacionadas con:
◾ Requisitos para establecer, implementar, mantener, evaluar y continuamente

Mejorar un sistema de gestión de seguridad de la información dentro del contexto de la organización.
ción. Estos requisitos son genéricos y están destinados a ser aplicables a todas las organizaciones,
independientemente del tipo, tamaño o naturaleza. (ISO / IEC 27001: 2013)
◾ Orientación para la implementación del sistema de gestión de seguridad de la información. (ISO / IEC DIS
27003)
◾ Pautas para implementar la gestión de la seguridad de la información (es decir, iniciar, implementar
mentar, mantener y mejorar la seguridad de la información) para intersectorial e intersectorial
comunicaciones organizacionales. (ISO / IEC 27010: 2015)
◾ ISO / IEC 27013: 2015. Orientación sobre la implementación integrada de un sistema de seguridad de la información
sistema de gestión de la propiedad, como se especifica en ISO / IEC 27001, y un sistema de gestión de servicios,
como se especifica en ISO / IEC 20000-1.
Página 163
El uso de la familia de estándares anterior ayudará a las organizaciones a administrar la seguridad de los activos,
incluyendo, pero no limitado a, información financiera, propiedad intelectual, detalles de empleados o
información confiada por terceros.
El propósito del marco ISO / IEC 27002 es ayudar a las organizaciones a seleccionar la seguridad adecuada
medidas de seguridad mediante la utilización de dominios disponibles de controles de seguridad. Cada dominio especifica el
objetivos que proporcionen más orientación sobre cómo las organizaciones pueden intentar implementar
marco de referencia.
El marco ISO / IEC 27002 debe elegirse cuando la alta dirección de TI (es decir, CIO)
apunta a una arquitectura de seguridad de la información que proporciona medidas de seguridad genéricas para cumplir
con las leyes y regulaciones federales.
Un marco conjunto
Como se ve, ITIL, COBIT e ISO / IEC 27002 son marcos relacionados con las mejores prácticas para
cumplimiento normativo y de gobierno corporativo. Sin embargo, un desafío para muchas organizaciones es
implementar un marco integrado que se base en estos tres estándares. El Marco Conjunto,
elaborado por el IT Governance Institute (ITGI) y el OGC, es un paso significativo que lidera
en esa dirección.
Alinear ITIL, COBIT e ISO / IEC 27002 no solo formaliza la relación entre
ellos, pero, lo más importante, permite a las organizaciones:
◾ implementar un método de cumplimiento único e integrado que proporcione

objetivos generales de control;
◾ cumplir con los requisitos reglamentarios de la normativa relacionada con los datos y la privacidad; y
◾ prepárese para la certificación externa según ISO 27001 e ISO 20000, las cuales demuestran
cumplimiento de las normas.
La implementación de un marco conjunto lleva a las organizaciones hacia un cumplimiento normativo efectivo y
mejora su competitividad. La implementación de los marcos recién discutidos es primordial en
abordar áreas relevantes dentro del campo de las TI. De igual importancia es el establecimiento de métricas
para medir el desempeño de TI. Estas métricas no solo deben estar en su lugar, sino que también deben evaluarse periódicam
para mantener la coherencia con las metas y objetivos de la organización.
Métricas de rendimiento de TI
El desarrollo de un proceso de medición requiere tiempo y recursos para implementarlo. Para tener éxito, ambos
la organización y la gestión de TI deben contar con un apoyo total. También deben ser consultados sobre
los tipos de medidas que creen que serán más beneficiosas. Las áreas a medir deben
estar estrechamente alineado con los objetivos de la organización. No tiene sentido medir algo
que a nadie le importa. La gerencia brindará su mayor apoyo cuando vea las métricas aplicadas
a las áreas que más necesitan mejorar. Normalmente, las áreas que se miden tienen un
tendencia a atraer la atención y mejorar con el tiempo. Un conjunto de métricas críticas: las pocas métricas clave que
son fundamentales para la gestión exitosa de la función; deben identificarse y aplicarse a la
medio ambiente.
Una vez que se ha identificado el conjunto de métricas críticas, el personal de las áreas que se van a medir
debe ser consultado, y un conjunto de mediciones que proporcionarán datos significativos deben ser
Página 164
ideado. El personal responsable de realizar el trabajo debe seleccionar los mejores medios para medir la
calidad y productividad de su trabajo. Las métricas que se desarrollan solo deben aplicarse a los datos
que son medibles y significativos. Es inútil perder tiempo desarrollando medidas sobre
áreas que no caen dentro del conjunto de métricas críticas, ya que estas medidas no satisfarán las necesidades de
administración.
Después de la implementación inicial de las primeras mediciones, es importante mostrar los resultados.
Los datos deben compilarse durante un período predefinido y los resultados deben proporcionarse a la gerencia
sobre una base regular. A medida que crece la base de datos de métricas, aumentará la confiabilidad de los datos y la
También aumentará la utilidad de los informes para la dirección.
Aunque es bastante fácil conseguir que la administración respalde las métricas (si están informados sobre qué
métricas y el impacto que pueden tener), también es difícil obtener apoyo de la gerencia si
son escépticos o no han sido educados al respecto. En esta situación, una tarea diferente debe ser
tomado. Primero, la gerencia debe darse cuenta de que es casi imposible administrar lo que
no se puede o no se mide. La forma más fácil de fortalecer este argumento es respaldarlo con
algunas métricas de muestra.
En segundo lugar, se pueden recopilar y presentar datos de encuestas de otras organizaciones para alentar
adopción de un estado de ánimo métrico. Para obtener métricas de muestra, identifique varias áreas que se pueden medir
asegurado y proporcionar informes sobre estas áreas. Una vez más, es importante proporcionar una recuperación a corto plaz
mostrar resultados y seguir produciendo informes que muestren el progreso en esas áreas.
Una vez que se recopilan todos los datos métricos, se deben presentar en un formato que sea fácil para el lector.
comprender. Una combinación de gráficos y texto es importante para ilustrar el contexto y la interpretación.
tendencias de formación. Los informes deben enfatizar el progreso en las áreas seleccionadas para la medición. Esta
es un punto clave porque muestra resultados a corto plazo en el proceso de medición a largo plazo. Areas de
Se debe enfatizar la mejora para mostrar que el proceso está funcionando.
Cuando la gerencia ha aceptado el concepto de métricas, es hora de comenzar a implementar
algunas mediciones en áreas críticas. Durante este paso del proceso de medición, es importante
ser sensible a la resistencia al cambio. La implementación de métricas genera malestar y
miedo en las filas.
La regla más importante a recordar en el diseño e implementación de una métrica es que en
En todos los casos, el área que se va a medir debe ayudar en el desarrollo de las métricas. Esta voluntad
crear un sentido de propiedad sobre las mediciones y aliviar la resistencia a su implementacin
tación. El grupo debe estar informado sobre las necesidades de gestión y debe estar empoderado
para desarrollar las métricas para satisfacer la necesidad. Esto resultará en la producción de datos más relevantes y
un aumento de la calidad en esa área.
La segunda regla importante a recordar en el diseño e implementación de una métrica es que
Es absolutamente vital que las medidas se apliquen a eventos y procesos, y nunca a individuos.
Si las personas tienen la idea de que se está midiendo su desempeño, será menos probable que cumplan
con el proceso de métricas. Debe declararse explícitamente que los resultados de las métricas no serán
utilizado para medir la productividad o eficacia de los individuos, sino de los procesos utilizados por el
individuos para crear sus productos o servicios.
Teniendo en cuenta estas dos reglas, el siguiente paso es identificar los atributos de una
medida. Una medida eficaz debe poder pasar pruebas de fiabilidad y validez. Fiabilidad
define la consistencia de una medida, y la validez determina el grado en el que realmente mide
asegura lo que se pretendía medir. La medida debe ser significativa y proporcionar
datos a la gerencia. Un ejemplo para medir el desempeño de TI es mediante la implementación de un
cuadro de mando avanzado.
Página 165
Cuadro de mando integral de TI

A medida que la implementación de sistemas de TI continúa creciendo rápidamente en las organizaciones, preguntas como
ya que lo siguiente se pregunta (y evalúa) con más frecuencia que nunca: ¿es nuestra
¿Plan de inversión en TI consistente con las metas y objetivos estratégicos de la organización? Fue el
aplicación acaba de desarrollar un éxito? ¿Se implementó de manera efectiva y eficiente? Es nuestra TI
departamento agregando valor a la organización? ¿Deberían subcontratar nuestros servicios de TI actuales a
¿terceros?
Este tipo de preguntas no son infrecuentes y apoyan las necesidades continuas de la organización.
Las operaciones tienen que medir el valor de TI y evaluar su desempeño. Esto es esencialmente lo que una TI
Balanced Scorecard (IBS) lo hace. Un IBS proporciona una imagen general del desempeño de TI alineado con
los objetivos de la organización. Mide y evalúa específicamente las actividades relacionadas con la TI (por ejemplo,
Proyectos de aplicaciones de TI, funciones realizadas por el departamento de TI, etc.) desde varias perspectivas
tivas, como el valor empresarial generado por TI, la orientación futura, la eficiencia operativa y la eficacia
ness y satisfacción del servicio del usuario final. Estas perspectivas se traducen luego en los correspondientes
métricas que se reconcilien con la misión y los objetivos estratégicos de la organización. Resultados de la
Las métricas se evalúan para determinar su adecuación con respecto a los valores objetivo y / o las iniciativas de la organiza
Los prospectos, que se describen a continuación, deben ser revisados periódicamente por el personal de administración para
Valor empresarial generado por TI

La medición del desempeño de TI depende de la estrategia y los objetivos de la organización.
Sin embargo, todo se reduce al valor comercial que TI le brinda a la organización. En general,
TI proporciona valor mediante la entrega de proyectos exitosos y el mantenimiento de las operaciones en funcionamiento. S
La organización está buscando costos reducidos, puede medir el costo de TI y la función comercial.
costo antes y después de la automatización. Si una organización se centra en el crecimiento de nuevos mercados, puede
medir el tiempo de comercialización de nuevos productos. TI agrega valor a una organización a través del proyecto
y prestación de servicios.
Los proyectos de TI brindan valor comercial al automatizar los procesos comerciales. Como estos proyectos son
habilitada por la tecnología, TI está agregando valor a la organización. Midiendo la cantidad de beneficio
entregado por estos proyectos es una forma de representar el valor de TI. Automatizar negocios
Los procesos suelen generar mayores costos de TI y menores costos comerciales (o mayores ingresos). Un origen
El caso de negocio del proyecto de desarrollo de aplicaciones nal hizo ciertas suposiciones sobre el costo y
beneficio de la nueva aplicación. Aunque el caso de negocio del proyecto se validará como parte del
revisión posterior a la implementación, es importante continuar midiendo los costos continuos a lo largo del tiempo.
Puede existir la percepción de que los costos de TI están creciendo sin el reconocimiento de que los costos comerciales
debería estar cayendo o los ingresos creciendo por un margen mayor . Es importante mantener esta información
ante el Consejo y la alta dirección como recordatorio del valor de las TI. Entrega
el valor prometido es responsabilidad tanto de TI como de las funciones comerciales. Informar sobre el
los resultados reales responsabilizan a ambas partes de los resultados esperados. Otra medida de valor es
la rapidez con la que la organización puede responder a nuevas oportunidades comerciales. Si ha tenido éxito
plena en la implementación de infraestructura, aplicaciones y procesos flexibles, podrá responder
a las necesidades empresariales.
Los servicios de TI brindan valor al estar disponibles para la organización según sea necesario. Organizaciones
dependen en gran medida de los sistemas automatizados para funcionar en el día a día. El fracaso de estos sistemas
resulta en pérdida de ingresos o aumento de gastos para la organización. Una perspectiva más positiva es
Página 166
la cantidad de ingresos o productividad generada por estos sistemas. Como parte de la estrategia y
proceso de planificación operativa, una organización debe decidir el nivel de servicio requerido de TI. los
Los niveles de servicio dependerán del tipo de organización, cartera de aplicaciones, servicios prestados por
TI y los objetivos de la organización. Una casa de subastas en línea que depende del servicio 24/7
la disponibilidad para su existencia tendrá una necesidad diferente a la de una tienda de abarrotes.
Las métricas para medir el valor comercial pueden abordar las funciones del departamento de TI, el valor
generado por proyectos de TI, gestión de inversiones en TI y ventas realizadas a terceros o terceros
corbatas. Estas métricas pueden incluir: porcentajes de recursos dedicados a proyectos estratégicos; percibido
relación entre la administración de TI y la administración de nivel superior; cálculo de tradicional
métodos de evaluación financiera, como el retorno de la inversión (ROI) y el período de recuperación ; real
versus gastos presupuestados; porcentajes por encima o por debajo del presupuesto total de TI; e ingresos de TI relacionados
servicios y / o productos; entre otros.
Orientación hacia el futuro

La orientación futura se ocupa de posicionar la TI para el futuro centrándose en lo siguiente
objetivos: (1) capacitar y educar al personal de TI para los desafíos futuros de TI; (2) mejorar el servicio
capacidades; (3) eficacia de la gestión del personal; (4) mejorar la arquitectura empresarial; y
(5) investigación de tecnologías emergentes y su valor potencial para la organización.
Una misión de muestra para esta perspectiva sería ofrecer una mejora continua y una
preparándose para los desafíos futuros. Las métricas de muestra dentro de esta perspectiva abordarían lo siguiente:
◾ Mejorar continuamente las habilidades de TI a través de la educación, la formación y el desarrollo.

◾ Entrega de proyectos internos consistentes con el plan.
◾ Métricas de dotación de personal por función (p. Ej., Utilizando índices de utilización / facturables, rotación voluntaria
nivel de rendimiento, etc.).
◾ Desarrollar y aprobar un plan de arquitectura empresarial y cumplimiento de sus estándares.
◾ Realización de investigaciones relevantes sobre tecnologías emergentes y su idoneidad para el
organización.
Eficiencia y efectividad operativa

La perspectiva de eficiencia y efectividad operativa se centra en los procesos internos establecidos
para entregar productos y servicios de TI de manera eficiente y eficaz. Las operaciones internas pueden
ser evaluados midiendo y evaluando los procesos de TI en áreas, tales como calidad, capacidad de respuesta,
seguridad y protección, entre otros. Otros procesos a considerar pueden incluir hardware y
suministro y soporte de software, gestión de problemas, gestión del personal de TI y la eficacia
tividad y eficiencia de los canales de comunicación actuales.
Las mediciones de la perspectiva de eficacia y eficiencia operativas pueden resultar en
datos sobre la productividad de diferentes procesos internos y recursos. Las métricas aquí pueden
producir información de productividad sobre el desempeño de tecnologías y de personal específico.
Satisfacción del servicio del usuario final

La satisfacción del usuario final debe desempeñar un papel importante en la evaluación general del departamento de TI.
ment o función. El usuario final, para fines de TI, puede ser personal interno o externo (por ejemplo, usuarios
acceder a sistemas o servicios de TI interorganizacionales, etc.). Desde la perspectiva del usuario final, el
Página 167
El valor de la TI se basará en si sus trabajos se completan de manera oportuna y precisa. Por ejemplo,
los gerentes confían en los informes generados por TI para tomar decisiones críticas relacionadas con su organización.
Estos informes no solo deben realizarse a tiempo, sino que deben ser precisos e involucrar
información para que puedan tomar decisiones comerciales bien informadas y necesarias.
Una misión para esta perspectiva sería entregar productos y servicios de valor agregado para fines
usuarios. Los objetivos relacionados incluirían mantener niveles aceptables de satisfacción del cliente,
asociaciones entre TI y empresas, rendimiento de desarrollo de aplicaciones y nivel de servicio
actuación. Las métricas utilizadas para medir los objetivos antes mencionados deben centrarse en tres áreas:
◾ ser el proveedor preferido para aplicaciones y operaciones

◾ establecer y mantener relaciones con la comunidad de usuarios
◾ satisfacer las necesidades del usuario final
Sería necesario que el personal de TI establezca y mantenga relaciones positivas con el

comunidad de usuarios para comprender y anticipar sus necesidades. Esa relación es fundamental
para construir y / o mejorar la credibilidad del departamento de TI entre los usuarios finales.
Pasos para crear un cuadro de mando integral de TI

Tener una comprensión de las estrategias de TI y de nivel corporativo, así como los objetivos específicos
relacionado con cada tipo de estrategia, es crucial antes de desarrollar un IBS. Se recomiendan los siguientes pasos
reparado al construir un IBS específico de la empresa:
1. Tener a bordo tanto la alta dirección como la dirección de TI desde el principio; hazlos
consciente con el concepto de IBS.
2. Coordinar la recopilación y análisis de datos relacionados con:
◾ estrategia y objetivos corporativos (p. Ej., Estrategia empresarial, estrategia de TI, misión de la empresa,
objetivos específicos de la empresa, etc.);
◾ métricas y métodos tradicionales de evaluación empresarial (p. Ej., ROI, período de recuperación, etc.)
implementado actualmente para la medición del desempeño de TI; y
◾ métricas potenciales aplicables a las cuatro perspectivas de IBS.
3. Definir los objetivos y metas específicos de la empresa del departamento de TI o área funcional.
desde cada una de las cuatro perspectivas.
4. Desarrollar un IBS preliminar basado en los objetivos y metas definidos de la organización y
los datos descritos en los pasos anteriores.
5. Solicite revisiones, comentarios y retroalimentación de la gerencia después de revisar el IBS.
6. Tener el IBS aprobado formalmente y listo para ser utilizado por la organización.
7. Comunicar el proceso de desarrollo de IBS y su razón fundamental a todas las partes interesadas.
El IBS proporciona valor al negocio cuando aborda los procesos de gestión de TI, que incluyen,
establecimiento de objetivos de TI individuales y de equipo, evaluación del desempeño y recompensas para el personal de T
asignación y aprendizaje basado en retroalimentación, entre otros. Tener un marco sistemático como el
El IBS que se basa en metas y medidas acordadas de antemano probablemente se beneficiará
gestión tanto de personas como de proyectos de TI.
Todas las métricas incluidas en el IBS deben ser cuantificables, fáciles de entender y aquellas para las que
los datos se pueden recopilar y analizar de manera rentable. Un ejemplo de IBS se ilustra en
Cuadro 5.1.
Página 168
Figura 5.1 Ejemplo de un cuadro de mando integral de TI
Valores objetivo /
Misión Objetivos Métrica a medir Iniciativas
Contribuir al
VALOR EMPRESARIAL GENERADO POR TI
valor del negocio
Valor comercial y - Finalización de estratégico

estratégico iniciativas
contribución de TI - Porcentaje de recursos
Departamento dedicado a estratégico
proyectos
- Relación percibida
entre la gestión de TI
y nivel superior
administración
Valor comercial de - Evaluación empresarial basada

Proyectos de TI sobre medidas financieras (ROI,
período de recuperación, etc.)
Gestión de TI - Real versus presupuestado

inversión gastos
- Porcentaje por encima / por debajo
presupuesto total de TI
Ventas a terceros - Ingresos relacionados con TI

o terceros servicios y / o productos
Para entregar continuo

mejora y
ORIENTACIÓN HACIA EL FUTURO
prepararse para el futuro
retos
Conocimiento - Finalización de la educación,

administración formación y desarrollo
cursos
- Porcentaje de puestos
con respaldo calificado
personal
- Experiencia con específicos
tecnologias
Capacidad de servicio Entregar proyectos internos a

mejora plan:
- Proceso interno
mejora
- Desarrollo organizacional
- Renovación tecnológica
- Desarrollo profesional
( Continuacion )
Página 169
Figura 5.1 ( continuación ) Ejemplo de un cuadro de mando integral de TI
Valores objetivo /
Gestión de personal Métricas de personal por función:

eficacia - Tasas de utilización / facturables
- Rotación voluntaria por
nivel de desempeño
- Porcentaje de personal con
profesional completo
planes de desempeño
Empresa - Desarrollo / aprobación de

arquitectura plan de arquitectura empresarial
evolución (EAP)
- Adhesión de sistemas a EAP
y estándares de TI
Emergente - Porcentaje del presupuesto de TI

tecnologias asignados a la investigación de nuevos
investigación y tecnologías actualizadas
Para entregar productos de TI

y servicios que son
EFICIENCIA Y EFECTIVIDAD OPERACIONAL
eficiente y
eficaz
Excelencia de proceso - Calificación de madurez del proceso y

rendimiento (es decir, calidad,
costo y velocidad)
Sensibilidad - Tiempo de ciclo de proceso y ciclo

hora de comprar
Reserva - Días de personal de trabajo presupuestado

administración y en estado de acumulación
envejecimiento - Días destacados de los más antiguos
trabajo presupuestado
Costo interno de - Tiempo / costo del proceso

calidad mejora y calidad
iniciativas de aseguramiento por TI
empleado
Seguridad y protección - Ausencia de problemas importantes en

informes de auditoría y
fallas irrecuperables o
brechas de seguridad
( Continuacion )
Página 170
Figura 5.1 ( continuación ) Ejemplo de un cuadro de mando integral de TI
Valores objetivo /
Para entregar productos

y servicios que suman SATISFACCIÓN DEL SERVICIO DEL USUARIO FINAL
valor para los usuarios finales
Usuario final - Puntuación en el usuario final

satisfacción encuesta de satisfacción
TI / negocios - Frecuencia de negocios de TI

camaradería Reuniones grupales
- Índice de usuarios y TI
participación en la generación
nueva aplicación estratégica
sistemas
Solicitud - Entrega a usuarios finales

desarrollo expectativas: calidad (usuario
actuación aceptación); presupuesto de gastos);
y velocidad (horario)
Nivel de servicio - Porcentaje ponderado de

actuación aplicaciones y operaciones
servicios servicio de reuniones
objetivos de nivel de disponibilidad
y rendimiento
Fuente: Adaptado de: Senft, S., Gallegos, F. y Davis, A. (2012). Tecnologías de la información
Control y Auditoría . CRC Press / Taylor & Francis, Boca Raton, FL; Adaptado de:
Martinsons, M., Davison, R. y Tse, D. (1999). El cuadro de mando integral: una base
para la gestión estratégica de sistemas de información, Decis. Soporte Syst ., 25 (1),
71–88.
Medir y evaluar las actividades de TI desde múltiples puntos de vista o perspectivas, por ejemplo
un IBS, por ejemplo, ayuda a evaluar la eficiencia, la eficacia y el potencial de esas actividades.
Dicho cuadro de mando permite a los gerentes evaluar el impacto de los sistemas, aplicaciones y actividades de TI en
los factores considerados importantes para la organización.
Cumplimiento normativo y controles internos

Uno de los procesos clave que las organizaciones deben administrar es el cumplimiento de las leyes y regulaciones.
La gran cantidad de leyes y regulaciones aplicables a una organización global puede ser abrumadora
(consulte el Capítulo 2). Puede ser necesario un equipo dedicado para examinar todos los aspectos financieros, de seguridad
y requisitos reglamentarios específicos de la industria para determinar el impacto en los procesos y la información
sistemas de Afortunadamente, muchos de los requisitos de TI se satisfacen con la implementación de
los controles descritos en COBIT.
Página 171
Existen herramientas que pueden ayudar a una organización a identificar leyes y regulaciones y realizar un seguimiento
procesos implementados para abordarlos. * También hay herramientas que pueden ayudar con la asignación de controles a
requisitos reglamentarios (por ejemplo, SOX de 2002, etc.). Estas herramientas brindan información clave para los auditores
reguladores y grupos de usuarios para determinar dónde los controles son efectivos para las pruebas y cuáles son los
vacíos que deberán ser llenados. TI debe trabajar junto con el oficial de cumplimiento de la organización
para asegurarse de conocer los nuevos requisitos e informar sobre la resolución de los requisitos existentes.
Como se mencionó anteriormente, la implementación de SOX creó una mayor conciencia y un mayor enfoque en TI
control S. Aunque existe cierto debate sobre el valor de SOX para las empresas, no hay duda de que
ha aumentado la inversión en controles generales de TI y controles de aplicaciones en muchas organizaciones.
El cumplimiento de SOX ha obligado a muchas organizaciones a revisar las aplicaciones existentes que procesan
transacciones comerciales con miras a controlar estos procesos. Profesionales de negocios y TI ahora
necesidad de trabajar juntos en el desarrollo de requisitos de control que se pueden incorporar en el desarrollo
Opción de aplicaciones. Tener más controles de TI implementados en los sistemas de aplicaciones se traduce
en más oportunidades para que los auditores de TI realicen trabajos de evaluación de controles.
Casos como los anteriores han llevado a las organizaciones a revisar y modificar su juego existente.
plan o estrategia de TI para que no solo cumplan con los organismos reguladores como SOX, sino también
cumplir con los requisitos en constante cambio de sus entornos empresariales.
Estrategia de TI
La TI se ha convertido en el ingrediente crítico en las estrategias comerciales como habilitador y potenciador de la
metas y objetivos de la organización. Las organizaciones deben estar posicionadas para aprovechar al máximo
oportunidades emergentes y al mismo tiempo responder a las necesidades globales del siglo XXI.
Una estrategia es un primer paso importante para cumplir con el desafiante y cambiante entorno empresarial.
ambiente. Una estrategia es una visión formal para guiar en la adquisición, asignación y gestión de
recursos para cumplir con los objetivos de la organización. Por ejemplo, se debería desarrollar una estrategia de TI
con la participación de los usuarios comerciales para abordar la dirección futura de la tecnología. La estrategia de TI
egy o plan estratégico de TI guía formalmente la adquisición, asignación y gestión de recursos de TI
coherente con las metas y objetivos de la organización. Debería ser parte de una estrategia corporativa global.
egy para TI y debe alinearse con la estrategia comercial que respalda. La estrategia tecnológica debe ser
en sintonía con la estrategia empresarial para garantizar que los recursos no se desperdicien en proyectos o procesos
que no contribuyen al logro de los objetivos generales de la organización. Esta alineación debería ocurrir
en todos los niveles del proceso de planificación para proporcionar una garantía continua de que los planes operativos
Continuar apoyando los objetivos comerciales. Apoyando la estrategia, estándares arquitectónicos y tecnología
La planificación de la energía garantiza que las inversiones en TI conduzcan a un mantenimiento eficiente y un entorno segu
El gobierno de TI (discutido al principio del capítulo) proporciona la estructura y la dirección para lograr
la alineación de la estrategia de TI con la estrategia empresarial. Estrecha alineación de la estrategia de TI
con la estrategia empresarial es esencial para el éxito de una asociación que funcione bien.
La estrategia más eficaz vendrá determinada por la combinación de medio ambiente, cultura,
y tecnología utilizada por una organización. La gestión de TI implica combinar tecnología, personas y
procesos para brindar soluciones a problemas organizacionales. TI debe tomar la iniciativa en la recopilación de información
ción para incorporar las necesidades organizacionales con la viabilidad tecnológica para crear una estrategia global.
Un plan estratégico de TI proporciona una hoja de ruta para los planes operativos y un marco para evaluar
inversiones en tecnología. La estrategia de TI respalda la estrategia comercial para garantizar que la tecnología
* Filipek, R., Automatización del cumplimiento, Auditor interno, febrero de 2007, págs. 27–29.
Página 172
Los recursos se aplican para cumplir con los objetivos comerciales mientras se minimizan los costos de soporte continuo.
Esta tarea parece bastante simple, pero según un informe de Gartner Group, “el 95% de las empresas carecen
una estrategia comercial bien definida ". En la mayoría de los casos, la estrategia empresarial debe asumirse en función de
conversaciones con ejecutivos de empresas. El primer paso para definir un plan estratégico de TI es comprender
Soportar los objetivos comerciales, ya sean establecidos o implícitos. Estos objetivos guían la gestión en
evaluar inversiones, evaluar riesgos e implementar controles.
Entonces, ¿por qué debería tener TI un plan estratégico si la organización no lo tiene? El principal riesgo de no tener
Un plan estratégico de TI es el aumento del costo de la tecnología. Si no hay una hoja de ruta, las organizaciones
corren el riesgo de invertir en tecnología que aumenta los costos pero no agrega valor comercial. Conforme
para el IT Governance Institute, alinear las inversiones en TI con las estrategias comerciales es la principal
las organizaciones de un solo tema enfrentan.
Dado que la TI existe para respaldar y habilitar las empresas, la responsabilidad última de establecer e implementar
La estrategia de TI debe recaer en la alta dirección de la organización. Sin embargo, el negocio
Los líderes necesitan que la administración de TI tome la iniciativa en la identificación de formas en que TI puede respaldar
de una organización para alcanzar sus metas a largo plazo. Una sólida asociación empresarial y de TI en el ámbito estratégic
El proceso de planificación proporciona la mejor base para el éxito. Una forma de lograr la alineación es involucrar
líderes empresariales en el desarrollo de la estrategia de TI mediante el establecimiento de un Comité Directivo de TI.
Comité Directivo de TI
Un Comité Directivo de TI está compuesto por tomadores de decisiones de los distintos distritos
la organización para resolver prioridades en conflicto. Incluso cuando los objetivos comerciales están claramente establecido
Surgirán conflictos con la interpretación de las acciones necesarias para cumplir con esos objetivos. los
El Comité Directivo de TI es responsable de determinar la estrategia general de inversión en TI, asegurando
que las inversiones en TI están alineadas con las prioridades comerciales y que los recursos de TI y comerciales están
disponible para permitirle a TI cumplir con sus expectativas.
Un comité directivo de TI puede ayudar a garantizar la integración del negocio y el plan estratégico de TI.
Este comité facilita la integración de estrategias, planes y operaciones de negocios y tecnología.
ciones empleando los principios de propiedad conjunta, trabajo en equipo, responsabilidad y comprensión
de grandes proyectos. El comité debe estar compuesto por miembros de la alta dirección y
CIO. El CIO, según Gartner, “supervisa a las personas, los procesos y las tecnologías dentro de una empresa
organización de TI de pany para garantizar que brinden resultados que respalden los objetivos de la empresa ". * En
En otras palabras, el CIO es clave para identificar iniciativas estratégicas, técnicas y de gestión críticas.
que se puede implementar para mitigar riesgos y amenazas, así como para impulsar el crecimiento empresarial. Esenciales
Las funciones del rol de CIO, tal como las describe la Society for Human Resource Management, † incluyen:
1. Crear, mantener e implementar políticas y procedimientos escritos con respecto a todas las computadoras
operaciones en el Departamento de Sistemas de Información de Gestión o TI y en todo el
organización.
2. Comunicar formalmente las políticas y procedimientos de sistemas de información nuevos o revisados a todos
usuarios dentro de la organización.
3. Revisar y evaluar la productividad del departamento, incluida la calidad de la producción y
costo del servicio. Implementar métodos y procedimientos para mejorar continuamente los resultados.
* www.gartner.com/it-glossary/cio-chief-information-officer/.
† https://www.shrm.org/resourcesandtools/tools-and-samples/job-descriptions/pages/default.aspx.
Página 173
4. Emplear las funciones necesarias para administrar el personal del departamento.

5. Desarrollar presupuestos anuales del departamento, segregando por actividad / personal, y administrar
fondos de acuerdo con la aprobación del presupuesto.
6. Mantenga la seguridad de todos los datos de propiedad de la organización y proporcione el
copia de seguridad de todos los sistemas informáticos en caso de fallo del sistema o desastre.
7. Adquirir, instalar y mantener todo el equipo informático (hardware y software) y todos
otros productos y suministros necesarios para mantener operativos los sistemas informáticos y para cumplir
solicitudes de gestión de soporte informático.
8. Actuar como enlace entre los proveedores de hardware / software y la dirección de la organización para obtener inform
Actualizaciones macionales y resolución de problemas.
9. Brindar a los empleados un servicio informático de alta calidad y disponibilidad constante, capacitación de apoyo.
ing y mantenimiento de todos los sistemas informáticos utilizados en toda la organización.
10. Evaluar nuevos equipos, software y procesos continuamente, recomendar cambios según sea apropiado.
priar y supervisar su instalación.
Como parte del Comité Directivo de TI, el CIO supervisa la estrategia de TI y los sistemas informáticos.
necesarios para apoyar los objetivos y metas de la organización. El Comité Directivo de TI ayuda
asegurar la integración de los objetivos y metas comerciales con la estrategia de TI. Para lograr esto, la TI
Las tareas del Comité Directivo pueden incluir:
◾ Revisión de planes y estrategias comerciales y tecnológicas.

◾ Priorizar grandes proyectos de desarrollo.
◾ Desarrollar estrategias de comunicación.
◾ Revisión de planes de desarrollo e implementación para todos los proyectos importantes.
◾
◾ Proporcionar
Monitoreo deldecisiones comerciales
estado, cronograma sobrede
e hitos lostodos
principales problemas
los proyectos de diseño para todos los proyectos importantes.
importantes.
◾ Revisar y aprobar solicitudes de cambios importantes para todos los proyectos importantes.
◾ Revisión de presupuestos de proyectos y ROI.
◾ Resolución de conflictos entre grupos empresariales y tecnológicos.
◾ Monitorear los beneficios comerciales durante y después de la implementación de grandes proyectos.
Una vez que el Comité Directivo de TI ha establecido una estrategia de TI, debe comunicarse
a todos los niveles de gestión ya los usuarios para asegurar la alineación y reducir los conflictos.
Comunicación
La comunicación eficaz es fundamental para coordinar los esfuerzos de los recursos internos y externos para
lograr los objetivos de la organización. La comunicación debe ocurrir en múltiples niveles, comenzando por
tener reuniones internas semanales del personal. Esto debería cubrir a los empleados dentro del departamento.
La comunicación también debe tener lugar a través de reuniones públicas, a las que suelen asistir (y
dirigido a) todos los empleados de la organización. Comunicación entre TI y la organización,
particularmente en asuntos como la estrategia de TI, los objetivos, etc., deben ser oportunos y coherentes. Comunicación
también debe incluir a todos los socios comerciales (externos) y clientes relacionados con la organización.
Después de completar el proceso de planificación estratégica, los objetivos comerciales y de TI deben ser
traducido en metas viables para el próximo año. Esto se realiza a través de un proceso llamado
planificación operativa.
Página 174
Planificación operativa
Una vez que se comprenden los objetivos de la organización y la estrategia de TI, esa estrategia necesita
para ser traducido en planes operativos (también llamado operacionalización). El plan operativo anual-
proceso incluye el establecimiento de las principales prioridades para la función de TI general, así como para las
Departamentos de TI, incluido el desarrollo de su presupuesto anual, la creación de planes de recursos y capacidad,
y preparar planes de desempeño individuales para todo el personal de TI.
Los planes operativos también identificarán y programarán los proyectos de TI que se iniciarán y
Se esperan niveles de servicio de TI. La entrega de estos planes debe estar controlada por una serie de
procesos. Estos procesos de gobernanza, que se enumeran en el cuadro 5.2, son necesarios para garantizar la eficacia
uso de recursos y entrega de proyectos de TI, así como una adecuada alineación con los objetivos comerciales.
Esto incluye procesos para: gestionar las demandas del proyecto, iniciar proyectos, realizar revisiones técnicas,
adquirir productos y gestionar proveedores, y controlar las inversiones financieras. Estos procesos son
explicado a continuación.
• Requisitos y caso comercial aprobados por la gerencia
• Costos de tecnología aprobados por TI

1. Demanda
administración
• Capacidad y niveles de servicio aprobados por la gerencia

• Recursos tecnológicos aprobados por TI
2. Proyecto
iniciación
• Diseño de solución aprobado por la gerencia
• Diseño técnico aprobado por TI

3. Técnico
revisión
• Requisitos y solución aprobados por la gerencia

4. Adquisiciones • Proveedores de tecnología aprobados por TI
y
administrador de proveedores.
• Alcance, cronograma y presupuesto aprobados por la gerencia y

ESO
5. Financiero • El progreso es monitoreado por la gerencia y el departamento de TI

administración
Figura 5.2 Procesos de gobierno.
Página 175
Gestión de la demanda
Los proyectos deben revisarse al comienzo de sus ciclos de vida para asegurarse de que tengan un fuerte
caso de negocio, así como apoyo a la alta dirección. Investigar soluciones tecnológicas lleva tiempo
y consume recursos que podrían dedicarse a proporcionar valor comercial. Una gestión de la demanda
El proceso de desarrollo puede ayudar a garantizar que los recursos se dediquen a proyectos que tengan un sólido caso de ne
y también aprobado por la alta dirección. El proceso de gestión de la demanda ayuda a garantizar que
La alta dirección está a bordo y ha proporcionado la aprobación conceptual del proyecto para continuar.
a través de las fases iniciales de definición de requisitos y diseño conceptual de la vida de desarrollo
ciclo. Todos los proyectos deben tener un patrocinador apropiado de la alta dirección antes de evaluar
los costos de implementar una solución. Esto es muy recomendable para evitar un esfuerzo inútil en un
proyecto que no será aprobado.
Un proceso de gestión de la demanda asegura que un proyecto tenga una justificación comercial, un negocio y
Patrocinador de TI y un enfoque coherente para aprobar proyectos. Un proceso de gestión de la demanda también
asegura la alineación de los grupos de aplicaciones e infraestructura; que todos los costos del proyecto estén identificados
para mejorar la toma de decisiones; que existen medios para "eliminar" los proyectos no esenciales; y eso
Se identifican los medios para controlar la capacidad y el gasto de TI.
Iniciación del proyecto

Una vez que se ha aprobado un proyecto con un sólido argumento comercial, debe someterse a un proceso de iniciación.
que determina su costo y beneficio total. Esto generalmente se hace definiendo los requisitos comerciales de alto nivel:
mentos y una solución conceptual. La elaboración de una estimación del proyecto requiere tiempo y recursos. Toma tiempo
de los usuarios comerciales para desarrollar requisitos y un caso comercial. También toma tiempo del software
desarrolladores para desarrollar una solución y estimaciones de costos. Una vez que un proyecto tiene la aprobación concept
Los usuarios y los programadores de software pueden trabajar juntos para desarrollar requisitos detallados y proyectos.
estimaciones que se utilizarán en el caso comercial final y formarán la base para el presupuesto del proyecto.
Revisión técnica
La solución técnica debe evaluarse antes de seguir adelante para garantizar el cumplimiento de
estándares tecnológicos. Un proceso de revisión técnica ayuda a garantizar que se seleccione la solución correcta,
que se integra eficazmente con otros componentes de la tecnología (por ejemplo, red, etc.), y que
puede apoyarse con inversiones mínimas en infraestructura. Una forma de controlar la tecnología
soluciones es implementar un Comité Directivo Técnico (que no debe confundirse con un Comité Directivo de TI
Comité) con representantes de las distintas disciplinas técnicas y arquitectos empresariales.
Un Comité Directivo Técnico proporciona un mecanismo de control para evaluar y aprobar nuevos
soluciones tecnológicas. Un proceso formal de evaluación de soluciones tecnológicas incluye las evaluaciones de:
◾ Viabilidad técnica
◾ Tecnologías alternativas
◾ Arquitectura
◾ Compatibilidad de habilidades internas
◾ Entornos / reemplazos existentes
◾ Consideraciones de implementación, licencias y costos
◾ Vistas de investigación y analistas
◾ Perfil de la empresa proveedora y viabilidad financiera
Página 176
Gestión de compras y proveedores

Deben existir procesos y procedimientos para definir cómo la adquisición de recursos de TI, incluyendo
Se realizarán ing personas, hardware, software y otros servicios. La adquisición de TI implica
tareas estratégicas y administrativas, como definir requisitos y especificaciones; ejecutando
el servicio de TI real o la adquisición de recursos (solo después de evaluar y seleccionar el
vendedor); y cumplimiento de los requisitos del contrato. La selección de proveedores generalmente implica la evaluación d
de tres a cinco proveedores. El Comité Directivo de TI evalúa periódicamente a los vendedores y proveedores de TI y
toma la decisión final sobre qué proveedores o proveedores incorporar.
Gestión financiera
En el proceso de gobernanza de la gestión financiera, las posibles inversiones, servicios y carteras de activos
Los lios se evalúan para que se incorporen en los análisis de costo / beneficio y, en última instancia, dentro del
presupuesto. El presupuesto de TI, por ejemplo, considera los productos, recursos y servicios de TI existentes en orden
para ayudar en la planificación de las operaciones de TI. El presupuesto es una herramienta de planificación estratégica (gen
en términos cuantitativos) que ayuda en el seguimiento de actividades y eventos específicos. Presupuestar también
proporciona pronósticos y proyecciones de ingresos y gastos que se utilizan estratégicamente para medir
actividades y eventos financieros. Los presupuestos son útiles para la administración al determinar si
Las actividades específicas de ingresos / costos están siendo controladas (es decir, los ingresos son más altos que el presupue
estimaciones o costos inferiores a los estimados del presupuesto). Los presupuestos lideran cómo las organizaciones
podría funcionar financieramente, operacionalmente, etc. en caso de que se lleven a cabo ciertas estrategias y / o eventos.
Conclusión
El gobierno de TI establece una base fundamental para la gestión de TI a fin de brindar valor a la organización.
Un gobierno eficaz alinea la TI con la organización y establece controles para medir el cumplimiento de esta
objetivo. Tres marcos relacionados con las tecnologías de la información eficaces y de mejores prácticas que las organizacio
son ITIL, COBIT e ISO / IEC 27002. Estos tres marcos proporcionan a las organizaciones valor
y los medios para abordar diferentes ángulos dentro del campo de la TI. Darse cuenta del valor de la TI requiere
una asociación entre la gerencia y TI. Esta asociación debe incluir la gestión empresarial
riesgo, así como establecer evaluaciones de desempeño de medición consistentes con las estrategias existentes
y metas. Estas medidas de desempeño deben estar alineadas con los objetivos de la organización,
dan como resultado datos precisos y oportunos, e informan las necesidades en un formato fácil de comprender.
Un ejemplo de una herramienta común para medir el desempeño de TI es el IBS. Un IBS proporciona una
panorama general del desempeño de TI alineado con los objetivos de la organización. Específicamente
mide y evalúa las actividades relacionadas con las TI, como los proyectos de TI y las funciones realizadas por el
Departamento de TI desde perspectivas como valor comercial generado por TI, orientación futura, operaciones
eficiencia y eficacia, y satisfacción del servicio al usuario final.
Establecer controles efectivos en TI y garantizar el cumplimiento normativo también es un esfuerzo conjunto.
La tecnología bien controlada es el resultado de una organización que considera los controles una prioridad.
Las organizaciones deben incluir controles en los requisitos del sistema para que esto suceda. Interna y
Los auditores externos pueden agregar un valor tremendo a una organización al brindar garantía independiente
que los controles funcionan según lo previsto. Con la implementación de SOX, los conocimientos y habilidades de
auditores es un recurso valioso para cualquier organización. Los auditores de TI pueden ayudar a la organización a documen
Mentar y evaluar las estructuras de control interno para cumplir con SOX u otros modelos de gobierno.
Página 177
Una estrategia es un primer paso importante para hacer frente al negocio desafiante y cambiante.
medio ambiente. Un plan estratégico de TI es una visión formal para guiar en la adquisición, asignación y
gestión de los recursos de TI para cumplir con los objetivos de la organización. Una forma de lograr la alineación
es involucrar a los líderes empresariales en el desarrollo del plan estratégico de TI mediante el establecimiento de una
Comité Directivo. El comité ayuda a garantizar la integración del plan estratégico comercial y de TI.
Asegurar el uso efectivo de los recursos y la entrega de proyectos de TI, así como la alineación adecuada
con los objetivos comerciales, las organizaciones emplean procesos de gobernanza dentro de sus operaciones anuales
plan de ing. Estos procesos abordan cómo gestionar las demandas del proyecto, iniciar proyectos, realizar
revisiones nicas, adquirir productos y administrar proveedores, y controlar las inversiones financieras.
1. ¿Cómo define COBIT la gobernanza?
2. Con respecto a la entrega de valor de TI, ¿por qué es tan importante para la empresa y su departamento de TI?
mento para unir esfuerzos?
3. Describa los tres marcos relacionados con las mejores prácticas de TI ampliamente reconocidos e indique cuándo
debe utilizarse cada marco.
4. Analice por qué las organizaciones deberían considerar implementar un marco conjunto entre ITIL,
COBIT e ISO / IEC 27002.
5. Explique qué es un cuadro de mando integral de TI.
6. El capítulo mencionó tres formas en las que TI puede aportar valor a la organización, a través de:
a. Implementar proyectos exitosos y mantener las operaciones en funcionamiento
segundo. Automatizar los procesos comerciales
C. Estar disponible para la organización según sea necesario
Explique con sus propias palabras cómo estos tres realmente aportan valor a las organizaciones.
Proporcione ejemplos que respalden cada uno.
7. ¿Qué es una estrategia? ¿Qué es un plan estratégico de TI y por qué es importante para alinear el negocio?
objetivos con TI?
8. ¿Qué es un Comité Directivo de TI? Resuma las diversas actividades incluidas como parte de su
alcance.
9. La operacionalización traduce la comprensión de los objetivos de la organización y de TI,
en planes operativos. Los planes operativos identifican y programan los proyectos de TI que se iniciarán
ated y los niveles de servicio de TI que se esperan. La entrega de estos planes operativos debe
ser controlado por una serie de procesos de gobernanza. Enumere y describa estos procesos.
10. ¿Qué es un Comité Directivo Técnico y qué evalúa en relación con una tecnología?
¿solución?
Ejercicios
1. Elija uno de los tres marcos relacionados con las TI ampliamente reconocidos y de mejores prácticas
discutido en el capítulo. Realice una investigación, fuera del capítulo, y proporcione lo siguiente:
a. Resumen del marco, incluidas las ventajas, desventajas y bajo qué
circunstancias debe ser adoptado por las organizaciones.
segundo. Proporcione dos o tres ejemplos del marco que se está utilizando, según corresponda.
Esté preparado para presentar su trabajo a la clase.
Página 178
2. Resuma los pasos para crear un Cuadro de Mando Integral de TI.

3. Describir las funciones esenciales de los directores de información en las organizaciones.
CASO — SIGNIFICADO DE TI
INSTRUCCIONES: Lea el artículo de Harvard Business Review "IT Doesn't Matter" de

Nicholas G. Carr.
TAREA: Resumir el artículo. Luego, indique si TI debería o no importar, y

por qué. Respalde sus razones y justificaciones con literatura de TI y / o cualquier otro externo válido.
fuente nal. Incluya ejemplos según corresponda para evidenciar su caso. Envíe una palabra
archivo con una portada, respuestas a las tareas anteriores y una sección de referencia al final. los
El archivo enviado debe tener entre 8 y 10 páginas (interlineado doble), incluida la portada.
página y referencias. Esté preparado para presentar su trabajo a la clase.
Otras lecturas
1. Anzola, L. (2005). Regulación de la gobernanza de TI: una perspectiva latinoamericana. Inf. Syst. Control J. , 2, 21.
2. Bagranoff, N. y Hendry, L. (2005). Elección y uso del software Sarbanes – Oxley. Inf. Syst. Controlar
J. , 2, 49–51.
3. Comité de Supervisión Bancaria de Basilea. (2010). Buenas prácticas para la gestión y supervisión
sión de riesgo operacional, Documento Consultivo, www.bis.org/publ/bcbs183.pdf
4. Brancheau, J., Janz, B. y Wetherbe, J. (1996). Temas clave en la gestión de sistemas de información:
1994–95 Resultados de SIM Delphi. MIS Q. , 20 (2), 225–242.
5. Burg, W. y Singleton, T. (2005). Evaluación del valor de la TI: comprensión y medición del vínculo
entre TI y estrategia. Inf. Syst. Control J. , 3, 44.
6. Carr, N. (2003). No importa, Harvard Business Review , Harvard Business School Publications,
Boston, MA.
7. Dietrich, R. (2005). Después del primer año: automatización de los controles de TI para el cumplimiento de Sarbanes-Oxley. Inf.
Syst. Control J. , 3, 53–55.
8. Guía de auditoría de tecnología global (GTAG) 17 Auditoría del gobierno de TI. (Julio de 2012). https: //na.theiia.
org / standards-guide / recommended-guide / practice-guides / Pages / GTAG17.aspx
9. Ho Chi, J. (2005). Regulación de la gobernanza de TI: una perspectiva asiática. Inf. Syst. Control J. , 2, 21-22.
10. Fundación de Auditoría y Control de Sistemas de Información. COBIT , 5ta edición, Sistemas de información
11. ISACA. (2012) COBIT 5: Un marco empresarial para el gobierno y la gestión de empresas
IT, 94.
12. ISO / IEC. 27001-Gestión de la seguridad de la información, https://www.iso.org/isoiec-27001-information-
security.html (enero de 2017).
13. Definición de la gobernanza de TI, www.itgovernance.co.uk/it_governance (consultado en 2017).
14. Instituto de Gobernanza de TI. (2008). Mapeo COBIT de ITIL V3 con COBIT 4.1, ISACA , Rolling
Meadows, IL. Digital.
15. Instituto de Gobernanza de TI. (2006). Mapeo COBIT de ISO / IEC 17799-2005 con COBIT 4.0 , ISACA,
Rolling Meadows, IL. Digital.
16. Instituto de Gobernanza de TI. (2007). Mapeo COBIT de NIST SP800–53 Rev 1 con COBIT 4.1 , ISACA,
Rolling Meadows, IL. Digital.
Página 179
17. Instituto de Gobernanza de TI. Informe de estado global sobre la gobernanza de la TI empresarial (GEIT) —2011,
http://www.isaca.org/Knowledge-Center/Research/Documents/Global-Status-Report-GEIT-2011_
res_Eng_0111.pdf
18. Schroeder, J. (6 de septiembre de 2015). Comparación de marco, NeverSys , http://neversys.com/wp-
content / uploads / 2015/09 / Framework-Comparison.pdf
19. Jones, W. (2005). Regulación de la gobernanza de TI: una perspectiva australiana. Inf. Syst. Control J. , 2, 20.
20. Kendall, K. (2007). Optimización del cumplimiento de Sarbanes-Oxley. Auditor interno , págs. 39–44.
21. KPMG. (2006). Aprovechamiento de TI para reducir costos y mejorar la capacidad de respuesta , KPMG International,
Nueva York.
22. Leung, L. (2007). ISACA presenta la certificación de gobierno de TI. Mundo de la red . www.networkworld.
com / newsletters / edu / 2007 / 0910ed1.html
23. Mack, R. y Frey, N. (11 de diciembre de 2002). Seis pilares para crear estrategias de TI reales ,
R-17-63607, Gartner Group, Stamford, CT.
24. Martinsons, M., Davison, R. y Tse, D. (1999). El cuadro de mando integral: una base para la
gestión estratégica de sistemas de información. Decis. Soporte Syst. , 25 (1), 71–88.
25. Parkinson, M. y Baker, N. (2005). Gobernanza empresarial y de TI. Inf. Syst. Control J. , 3.
26. Pohlman, MB (2008). Marcos de cumplimiento. Oracle Identity Management: gobernanza, riesgo y
Arquitectura de cumplimiento , tercera edición, Auerbach Publications, Nueva York. www.infosectoday.com/
Artículos / Compliance_Frameworks.htm
28. Van Grembergen, W. y De Haes, S. (2005). Medir y mejorar la gobernanza de TI a través del
Cuadro de mando integral. Inf. Syst. Control J. , 2, 35.
29. Van Grembergen, W. (2000). El cuadro de mando integral y el gobierno de TI. Desafíos de la información
gestión de tecnología en el siglo XXI, 2000 Information Resources Management Association
Conferencia internacional, Anchorage, AL, 21 al 24 de mayo, https://www.isaca.org/Certification/CGEIT-
Certificado-en-el-gobierno-de-la-TI-empresarial / Preparación-para-el-examen / Materiales-de-estudio / Documentos /
Cuadro de mando integral y gobernanza de TI.pdf
30. Williams, P. (2005). Alineación de TI: ¿Quién está a cargo? Instituto de Gobernanza de TI, Rolling Meadows, IL.
Página 181
180
Capítulo 6
Gestión de riesgos
1. Analice el proceso de gestión de riesgos y cómo juega un papel importante en la protección
información de las organizaciones de las amenazas de TI.
2. Describir la gestión de riesgos empresariales: marco integrado, así como sus ocho riesgos
y componentes de control, y cómo se aplican a los objetivos establecidos por la dirección.
3. Explique qué es la evaluación de riesgos en el contexto de una organización.
4. Resumir los estándares
evaluaciones de riesgo.profesionales que brindan orientación a los auditores y gerentes sobre
5. Respaldar la necesidad de cobertura de seguro como parte del proceso de evaluación de riesgos para las operaciones d
Este capítulo analiza el proceso de gestión y evaluación de riesgos en un entorno de TI. Riesgo
La gestión debe integrarse en la planificación estratégica, la planificación operativa, la gestión de proyectos.
mento, asignación de recursos y operaciones diarias. La gestión de riesgos permite a las organizaciones concentrarse
en las áreas que tienen el mayor impacto. Las evaluaciones de riesgo, por otro lado, ocurren en múltiples niveles.
de la organización con foco en diferentes áreas. La dirección ejecutiva puede centrarse en los negocios
riesgos, mientras que el oficial de tecnología se enfoca en los riesgos de tecnología, el oficial de seguridad se enfoca en la se
los riesgos de capital y los auditores se centran en los riesgos de control. Pero, ¿cuáles son las características y componentes
un proceso de gestión de riesgos? ¿Cuáles son los estándares profesionales de práctica para las evaluaciones de riesgos?
¿Cuáles son ejemplos de prácticas de evaluación de riesgos que se utilizan en diversos entornos? ¿Por qué el seguro
cobertura tan importante cuando se trata de evaluaciones de riesgo? ¿Cuáles son los riesgos normalmente asegurados?
Estas son algunas de las preguntas que se responderán en el capítulo.
Gestión de riesgos
La mala gestión del riesgo puede conllevar un coste enorme. En los últimos años, las empresas han experimentado
numerosas reversiones asociadas al riesgo que han resultado en pérdidas financieras considerables, disminución en
valor para el accionista, daño a la reputación de la organización, despidos de la alta dirección y
en algunos casos, disolución del negocio. Este entorno cada vez más riesgoso incita a la gestión
mento para adoptar una perspectiva más proactiva en la gestión de riesgos.
155
Página 182
La gestión de riesgos garantiza que las pérdidas no impidan que la dirección de las organizaciones busque
sus objetivos de conservación de activos y realización del valor esperado de las inversiones. El Nacional
La Publicación Especial (SP) 800-30 del Instituto de Estándares y Tecnología (NIST) * define la gestión de riesgos
gestión como el proceso de identificación y evaluación de riesgos, seguido de la implementación de los
procedimientos para reducir dicho riesgo a niveles aceptables. La gestión de riesgos juega un papel importante en
proteger la información de las organizaciones de las amenazas de TI. Por ejemplo, la gestión de riesgos de TI se centra
sobre los riesgos resultantes de los sistemas de TI con amenazas como fraude, decisiones erróneas, pérdida de producción
tiempo limitado, inexactitud de los datos, divulgación de datos no autorizada y pérdida de la confianza pública que puede
poner en riesgo a las organizaciones. Un proceso de gestión de riesgos de TI bien diseñado es esencial para desarrollar
un programa de seguridad exitoso para proteger los activos de TI de una organización. Cuando se usa de manera efectiva,
Una metodología de gestión de riesgos bien estructurada ayudará a la dirección de las organizaciones a identificar
ing controles adecuados para apoyar sus sistemas de TI.
Históricamente, la gestión de riesgos, incluso en las empresas más exitosas, ha tendido a estar en
"Silos": el riesgo de seguros, el riesgo tecnológico, el riesgo financiero y el riesgo ambiental, todos
gestionado de forma independiente en compartimentos separados. La coordinación de la gestión de riesgos ha
ha sido inexistente y la identificación de riesgos emergentes ha sido lenta.
El marco de gestión de riesgos empresariales (ERM) de COSO define el riesgo empresarial
gestión de la siguiente manera:
Un proceso, efectuado por la junta directiva de una entidad, la gerencia y otra persona-
nel, aplicado en el establecimiento de estrategias y en toda la empresa, diseñado para identificar el potencial
eventos que puedan afectar a la entidad, y gestionar los riesgos para que estén dentro de su apetito por el riesgo, para
proporcionar seguridad razonable con respecto al logro de los objetivos de la entidad. †
A primera vista, hay mucha similitud entre ERM y otras clases de riesgo (por ejemplo, crédito ,
mercado , liquidez , riesgo operacional , etc.) y las herramientas y técnicas que se les aplican. De hecho,
los principios aplicados son casi idénticos. ERM debe identificar, medir, mitigar y monitorear
riesgo. Sin embargo, a un nivel más detallado, existen numerosas diferencias, que van desde el riesgo
ellos mismos a las habilidades necesarias para trabajar con riesgo operacional.
ERM se ha vuelto más aceptado como un medio de gestión de organizaciones. En una encuesta
realizado por la Asociación Internacional de Gestores de Riesgos Profesionales, más del 90% de los
Los dentistas creían que ERM es o será parte de sus procesos comerciales. ¿Deberían las organizaciones
poder desarrollar programas ERM exitosos, el próximo paso será para estas organizaciones
para integrar ERM con todas las demás clases de riesgos en una gestión de riesgos verdaderamente empresarial
marcos.
Los altos directivos deben fomentar el desarrollo de sistemas integrados que agreguen
riesgos crediticios, de mercado, de liquidez, operativos y de otro tipo generados por las unidades de
marco en toda la organización. La coherencia puede convertirse en una condición necesaria para
aprobación de modelos internos de gestión de riesgos. Un entorno donde cada unidad de negocio calcula
establece su riesgo por separado con diferentes reglas no proporcionará una supervisión significativa de la empresa
amplio riesgo. La creciente complejidad de los productos, los vínculos entre los mercados y los beneficios potenciales
que ofrecen los efectos de la cartera general están empujando a las organizaciones hacia la estandarización e integración
gestión de riesgos.
* http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.
† Gestión de riesgos empresariales: marco integrado. Comité de Organizaciones Patrocinadoras del
Comisión Treadway. Septiembre de 2004, pág. 2. www.coso.org/documents/coso_erm_-executivesummary.pdf.
Página 183
Gestión de riesgos ◾ 157
Gestión de riesgos empresariales: marco integrado

La defensa más sólida contra el riesgo operativo y las pérdidas reside y fluye desde el nivel más alto
de la organización: la Junta y la alta dirección. La Junta, el equipo directivo que
contratar, y las políticas que desarrollan, establecen el tono para una organización. Como guardianes de la participación
valor del tenedor, la Junta debe estar muy en sintonía con la reacción del mercado a las noticias negativas. De hecho,
pueden verse castigados por el público si la reacción es lo suficientemente severa. Como representante
tivas de los accionistas, los miembros de la Junta son responsables de las cuestiones de política relativas a
gobernanza, que incluye, entre otros, preparar el escenario para el marco y la base
para ERM.
En 2010, el Comité de Gestión de Riesgos de Basilea emitió una guía actualizada sobre la gestión de operaciones
riesgo nacional que destaca aún más la importancia de la gestión del riesgo empresarial. Mientras tanto,
los accionistas son conscientes de los riesgos operativos que pueden sumar miles de millones de dólares cada año y
incluyen pérdidas frecuentes de bajo nivel y también pérdidas poco frecuentes pero catastróficas que en realidad
acabó con las empresas. Los reguladores y accionistas ya han señalado que mantendrán la
Directorio y ejecutivos responsables de la gestión del riesgo operativo.
ERM — Integrated Framework, desarrollado por COSO, es una herramienta eficaz para los altos directivos
gestión y la Junta para establecer metas y estrategias; identificar, evaluar y gestionar áreas de riesgo; Seleccione
e implementar controles para mitigar o abordar las áreas de riesgo; y asegurarse de que la empresa
logra sus objetivos y metas de manera mada.
El modelo ERM — Marco Integrado se ilustra en el Cuadro 6.1. Las cuatro columnas superiores
son los objetivos que la dirección suele establecer para alcanzar las metas de la empresa. los
El lado derecho del modelo muestra las cuatro unidades que pueden componer una empresa. El modelo también
muestra los ocho componentes específicos interrelacionados del ERM. Estos ocho componentes de riesgo y control
componentes se aplican a cada uno de los cuatro objetivos de gestión, así como a las unidades de la empresa en el
lado derecho del modelo.
Objetivos de manejo
Nivel de entidad
División
Estratégico norte
Operaciones Reportando Conformidad
yo
Componentes COSO-ERM
Unidad de negocio
t
1. Entorno interno
2. Establecimiento de objetivos
s
3. Identificación de eventos (o riesgos)
Subsidiario
4. Evaluación de riesgos
5. Respuesta al riesgo
6. Actividades de control
7. Información y comunicación
8. Seguimiento
Figura 6.1 Modelo COSO-ERM.
Página 184
El ERM: Marco Integrado adopta un enfoque basado en riesgos en lugar de controles.

al evaluar los controles internos, como es el caso de los COSO ampliamente adoptados y requeridos por SOX
Control interno: marco integrado (“marco de CI”). El enfoque ERM basado en riesgos
resultado de la adición de cuatro elementos al marco de CI anterior: establecimiento de objetivos,
Identificación de eventos (o riesgos), evaluación de riesgos y respuesta a los riesgos. Estos elementos adicionales para
El marco de CI hace que el Marco Integrado de ERM sea más completo para ayudar
empresas con no solo establecer metas y evaluar riesgos, sino también identificar e implementar
procedimientos para controlar el riesgo (es decir, aceptar, evitar, diversificar, compartir o transferir el riesgo). Los ocho comp
Los elementos del marco se describen a continuación.
Ambiente interno
El entorno interno de una empresa lo es todo. Se refiere a su cultura, sus comportamientos, su
acciones, sus políticas, sus procedimientos, su tono, su corazón. El entorno interno es crucial en el establecimiento
las metas, estrategias y objetivos de la empresa; establecer procedimientos para evaluar o mitigar el riesgo
Areas de negocio; e identificar e implementar controles adecuados para responder a esas áreas de riesgo.
Un entorno interno sólido a menudo evita que una empresa sufra fallas en la gestión de riesgos.
y control. El entorno interno es la base y la infraestructura de los otros siete ERM
componentes, y consta de:
◾ Creencias, actitudes, estilo operativo y apetito por el riesgo de la gerencia.

◾ Compromiso de la dirección con la integridad, los valores éticos y la competencia.
◾ Supervisión de la dirección sobre la estructura y el control interno de la empresa.
◾ Métodos de asignación de autoridad y responsabilidad mediante el establecimiento de
políticas y procedimientos que sean consistentes con las metas y objetivos.
◾ Políticas, procedimientos y prácticas de recursos humanos que supervisan las condiciones laborales existentes,
incentivos laborales, promoción y avance profesional.
◾ Procedimientos establecidos para cumplir con los requisitos externos de la industria, así como con los
leyes, como las impuestas por bancos, servicios públicos, compañías de seguros, la SEC y la
PCAOB, entre otros.
Establecimiento de objetivos
Los objetivos se refieren a las metas que la empresa quiere alcanzar. Los objetivos se establecen en varios
niveles dentro de una empresa. Es decir, las empresas pueden establecer objetivos a nivel superior / gerencial,
decir para guiar su dirección o estrategia (por ejemplo, convertirse en el mejor vendedor del mercado, adquirir un
separar negocios, fusionarse con un competidor, etc.); o en niveles inferiores, como mejorar los
operaciones (por ejemplo, contratar personal de calidad, mejorar los procesos actuales, implementar controles
para abordar riesgos adicionales, manteniendo ciertos niveles de producción, etc.). Las empresas también pueden
establecer metas para propósitos de informes y cumplimiento. Se establecen objetivos similares a los informes, por ejemplo,
para garantizar la confiabilidad, integridad y precisión de los informes (por ejemplo, estados financieros, etc.). Estas
los objetivos se logran mediante la protección adecuada de los sistemas de aplicación financiera, así como
la realización de revisiones de gestión oportunas y exhaustivas, por ejemplo. Objetivos de cumplimiento, en
Por otro lado, asegúrese de que todas las leyes aplicables específicas de la industria, locales, estatales y federales sean
seguido y observado. El incumplimiento de estos puede resultar en graves consecuencias, dejando
la empresa vulnerable a juicios, auditorías bajo demanda y sanciones que pueden conducir en última instancia a
disolución.
Página 185
Identificación de eventos (o riesgos)

Los eventos impactan a las empresas interna o externamente. Por ejemplo, los eventos pueden ocurrir fuera del
empresa (por ejemplo, desastres naturales, promulgación de nuevas leyes y reglamentos, etc.) que pueden significar
afectar de manera significativa sus metas, objetivos y / o estrategia. La identificación de estos eventos o riesgos puede result
de responder a preguntas de gestión, tales como: (1) ¿Qué podría salir mal? (2) ¿Cómo puede ir?
¿incorrecto? (3) ¿Cuál es el daño potencial? y (4) ¿Qué se puede hacer al respecto? Un ejemplo sería
ser un fabricante de escritorios de oficina que confía en obtener la madera necesaria para construir los escritorios de
regiones específicas del Caribe. El objetivo organizativo del fabricante es mantenerse al día
niveles de demanda de producción. Entonces, aquí están las preguntas de administración de arriba con hipotéticos
respuestas para identificar eventos internos o externos:
1. ¿Qué podría salir mal? El envío de madera puede fallar o no recibirse a tiempo, lo que resulta
en no tener suficiente madera suministrada para satisfacer las demandas de los clientes y / o la producción requerida
niveles.
2. ¿Cómo puede salir mal? Las condiciones climáticas (por ejemplo, huracanes, inundaciones, etc.) pueden afectar la seg
condiciones para cortar árboles y preparar la madera necesaria; o evitar el envío oportuno del
madera al sitio de fabricación.
3. ¿Cuál es el daño potencial? La falta o el suministro limitado pueden provocar que el fabricante
mayores costos que podrían traducirse en mayores costos y precios para los clientes.
4. ¿Qué se puede hacer al respecto? Las soluciones pueden incluir identificar al menos uno o dos
proveedores (fuera del Caribe), y / o tener mayores cantidades de inventario de madera en
mano. Esto ayudará a prevenir o mitigar los problemas que se acaban de identificar y garantizará que
Los niveles mínimos de producción se mantienen consistentes con los objetivos organizacionales.
La clave es identificar eventos o riesgos potenciales que pueden afectar significativamente las operaciones comerciales.
e ingresos. Los riesgos se clasifican como inherentes (existen antes de que se hagan planes para controlar
ellos) o residuales (riesgos que quedan después de ser controlados), y se pueden identificar mediante:
◾ Auditorías o inspecciones por parte de gerentes, trabajadores o partes independientes de la empresa.

sitios o prácticas operativas
◾ Operaciones o diagramas de flujo de procesos de las operaciones de la empresa
◾ Cuestionarios de análisis de riesgos donde se puede capturar información sobre el
operaciones y actividades en curso
◾ Análisis de estados financieros para representar tendencias en áreas de ingresos y costos, identificando activos
análisis de exposición
◾ Listas de verificación de pólizas de seguros
En vista de la mayor dependencia de las tecnologías de la información y los sistemas automatizados, se debe poner especial
en la revisión y análisis de riesgos en estas áreas. Las instalaciones de TI y el hardware a menudo se incluyen en
la revisión general de la planta y la propiedad de la empresa; sin embargo, los sistemas automatizados requieren un
análisis, especialmente cuando estos sistemas son la única fuente de información crítica para la empresa
como en los entornos actuales de comercio electrónico. Existen muchos riesgos que afectan al entorno de TI actual.
Las empresas enfrentan pérdidas por eventos tradicionales, como desastres naturales, accidentes, vandalismo y
robo, y también de hechos similares en formato electrónico. Estos pueden resultar de virus informáticos,
Página 186
robo de información o datos, sabotaje electrónico, etc. Algunos ejemplos de recursos para ayudar
en la identificación y evaluación de estos riesgos relacionados con las TI incluyen:
◾ NIST.gov . El NIST ha sido líder en el suministro de herramientas y técnicas para respaldar la TI. Eso
tiene una serie de herramientas de soporte que pueden ser utilizadas por organizaciones privadas pequeñas y grandes
fines de evaluación de riesgos.
◾ GAO.gov . La Oficina de Responsabilidad del Gobierno de EE. UU. (GAO) ha proporcionado una serie de
recursos de auditoría, control y seguridad, así como la identificación de las mejores prácticas en la gestión
y revisar el riesgo de TI en muchas áreas.
◾ Enfoque de pérdida esperada . Un método desarrollado por IBM que evalúa la pérdida probable y la
frecuencia de ocurrencia de todos los eventos inaceptables para cada sistema automatizado o archivo de datos.
Los eventos inaceptables se clasifican como: divulgación accidental o deliberada; accidental
o modificación deliberada; o destrucción accidental o deliberada.
◾ Enfoque de puntuación . Identifica y sopesa varias características de los sistemas de TI. El enfoque
utiliza la puntuación final para comparar y clasificar su importancia.
Una vez identificados, los riesgos se evalúan, lo que significa que la probabilidad de sus pérdidas potenciales es cuantitativa
tificado y clasificado. Los riesgos se evalúan desde dos perspectivas: probabilidad e impacto. Probabilidad
se refiere a la probabilidad de que ocurra el evento. El impacto, por otro lado, es el estimado
pérdida potencial si ocurriera tal evento en particular. Los riesgos se clasifican de la siguiente manera:
◾ Crítico: las exposiciones resultarían en la quiebra, por ejemplo.

◾ Importante: las posibles pérdidas no conducirían a la quiebra, pero requerirían que la empresa
Emitir préstamos para continuar las operaciones.
◾ Sin importancia: exposiciones que podrían adaptarse a los activos existentes o los ingresos actuales.
sin imponer una tensión financiera indebida.
Asignar los riesgos identificados a una de las categorías anteriores les otorga un nivel de importancia y ayuda
determinar los medios adecuados para tratar dichos riesgos. La evaluación de riesgos se discute con más detalle.
en una sección posterior.
Respuesta a los riesgos

Después de evaluar los riesgos, el siguiente paso es elaborar un plan de acción y determinar los
técnica (s) para responder a los riesgos identificados. Normalmente, el proceso de respuesta al riesgo comienza con
empresas que evalúan sus riesgos inherentes, luego seleccionan la técnica de respuesta adecuada, y
finalmente evaluando el riesgo residual. La gerencia puede reaccionar o responder a los riesgos identificados en uno de los
las siguientes cuatro formas: evitar, prevenir, reducir o transferir.
◾ Evite o elimine completamente el riesgo. Por ejemplo, una nueva función incluida en el siguiente
Se estima que la versión del software de la aplicación degradará el rendimiento de la aplicación al disminuir la
algún procesamiento crítico. Para evitar el riesgo, la función de software se elimina del
próxima versión.
◾ Prevenir un riesgo mediante la implementación de controles de TI, como (1) realizar verificaciones de validez
al ingresar datos; (2) limpieza de unidades de disco y almacenamiento adecuado de magnéticos y ópticos
medios para reducir el riesgo de fallas de hardware y software; (3) configurar el ajuste lógico
controles de seguridad (es decir, contraseñas) en el sistema de aplicación.
Página 187
Figura 6.2 Técnicas de respuesta al riesgo
Respuesta a los riesgos

Ejemplos de preguntas antes de elegir una técnica Técnica
• ¿Es imposible evitar el riesgo? Evitación

• ¿Es poco práctico evitar el riesgo?
• ¿Es demasiado caro evitar el riesgo?
• ¿El riesgo requiere demasiado tiempo para evitarlo?
• ¿Existen controles para evitar que ocurra el riesgo? Prevención

• Si es así, ¿son estos controles rentables? (es decir, los beneficios de
implementar los controles supera sus costos?)
• ¿Existen controles efectivos que reduzcan el riesgo? (es decir, el Reducción

los beneficios de implementar los controles superan sus costos?)
• ¿Se reducirán también otros riesgos a partir de los controles implementados?
• ¿Se puede transferir el riesgo a un tercero mediante la compra? Transferir

¿seguro?
• ¿Se puede reducir y transferir parcialmente el riesgo?
◾ Reducir el riesgo tomando acciones de mitigación, como tener controles que detecten errores
después de que los datos estén completos. Ejemplos de estos incluyen la implementación de revisiones de acceso de u
realizar conciliaciones y realizar controles de transmisión de datos, entre otros.
◾ Transferir todo o parte del riesgo a un tercero. Los métodos comunes de transferencia de riesgos incluyen
adquirir servicios de seguros o de subcontratación (subcontratación). Como ejemplo, una empresa
que necesita actualizar su sistema de aplicación financiera puede optar por subcontratar o subcontratar
tal proyecto (junto con todos sus riesgos) a un extraño.
Una última opción implicaría que la administración asumiera o retuviera el riesgo. Es decir, después de evaluar el
riesgo, la gerencia se siente cómoda al conocer el riesgo y decide seguir adelante con él. Un
ejemplo aquí sería un inversor que asume el riesgo de que una empresa esté comprando la propiedad
(stock) de probablemente quebrará. Se puede aplicar más de una técnica a un riesgo determinado (p. Ej.,
el riesgo se puede reducir, luego transferir, etc.). Los objetivos de gestión de riesgos de TI deben utilizarse como
una guía para elegir una técnica. El cuadro 6.2 muestra preguntas clave comunes de TI y administración
el personal pregunta antes de seleccionar entre las cuatro técnicas de respuesta mencionadas anteriormente.
Una vez que se ha elegido la técnica adecuada, se debe implementar. Las tecnicas
implementado debe ser evaluado y revisado con frecuencia. Esto es importante porque
las variables que se incluyeron en la selección de una técnica anterior pueden cambiar. Técnicas que fueron
El año pasado apropiado puede no serlo este año y pueden ocurrir errores. La aplicación de la
Las técnicas incorrectas deben detectarse temprano y corregirse.
Actividades de control
COBIT define las actividades de control como las “políticas, procedimientos, prácticas y estructura organizativa
medidas diseñadas para proporcionar una seguridad razonable de que se lograrán los objetivos comerciales y que
los eventos no deseados serán prevenidos o detectados y corregidos ”. En otras palabras, las actividades de control (o
controles) son procedimientos que la gestión implementa para salvaguardar los activos, mantenerlos precisos y completos.
información, así como lograr las metas y objetivos comerciales establecidos. Implementando controles
es una forma eficaz de: (1) reducir los riesgos identificados a niveles aceptables; (2) cumplir con la empresa
Página 188
políticas, procedimientos, leyes y regulaciones; y (3) mejorar la eficiencia de las operaciones existentes. Una vez
establecidos, los controles deben ser monitoreados para una implementación efectiva. También deben evaluarse para
determinar si funcionan de manera eficaz y como se esperaba cuando se diseñaron originalmente.
Hay tres tipos de controles: preventivo, detective y correctivo. La gerencia debe
identificar e implementar controles de los tres tipos anteriores para proteger a la empresa
de eventos no deseados. Los controles preventivos, por ejemplo, disuaden de que ocurran problemas y son
generalmente superior a los controles de detectives. Ejemplos de controles preventivos incluyen la contratación de personal
personal, segregando las funciones de los empleados y controlando el acceso físico. El segundo tipo de
Los controles, controles detectivescos, están destinados a descubrir problemas que no se pueden prevenir. Ejemplos
de un control detectivesco incluyen la realización de conciliaciones de cuentas bancarias, balances de prueba, etc.
Los controles de detective están diseñados para activarse cuando fallan los controles preventivos. Controles correctivos, el
tercer tipo de controles, están diseñados para identificar, corregir y recuperarse de los problemas identificados
fied. Al igual que los controles de detectives, los controles correctivos "reaccionan a lo que acaba de suceder". Ejemplos
incluyen el mantenimiento de copias de seguridad de los archivos y la corrección de errores de entrada de datos. Un interno
El sistema de control debe implementar los tres tipos de controles. Áreas donde se pueden implementar controles
incluyen, entre otros, la segregación de funciones; aprobación y autorización de transacciones;
gestión del cambio; protección de activos, registros y datos; y comprobaciones del rendimiento de los sistemas y
supervisión.
Información y comunicación
Describir el séptimo componente del ERM: modelo de Marco Integrado, información y
comunicación, es fundamental explicar qué es la información y a qué se refiere la comunicación.
Las empresas necesitan información para llevar a cabo sus responsabilidades de control interno y, en última instancia, para
apoyar el logro de sus metas y objetivos comerciales. La información son datos organizados y
procesados para dar sentido y, así, mejorar la toma de decisiones. La gerencia necesita que tales
información, generada a partir de fuentes internas o externas, sea útil (es decir, información de calidad
ción) con el fin de tomar decisiones comerciales efectivas y eficientes, así como para respaldar adecuadamente
el funcionamiento de su sistema de control interno. La información es útil cuando es:
1. Relevante : la información es pertinente y aplicable para tomar una decisión (por ejemplo, la decisión de
extender el crédito del cliente necesitaría información relevante sobre el saldo del cliente de un
Informe de antigüedad de cuentas por cobrar, etc.).
2. Confiable : la información está libre de sesgos, es confiable y confiable.
3. Completo : la información no omite aspectos importantes de eventos o actividades.
4. Oportuna : la información debe proporcionarse a tiempo para tomar la decisión.
5. Comprensible : la información debe presentarse de manera significativa.
6. Verificable : dos o más personas independientes pueden llegar a la misma conclusión.
7. Accesible : la información está disponible cuando se necesita.
La comunicación, por otro lado, se refiere al proceso de proporcionar, compartir y obtener

información necesaria de forma continua y frecuente. La comunicación de información podría
ocurren internamente dentro de la empresa (por ejemplo, mensaje del CEO o CIO a todos los empleados de la empresa
ees, etc.) o externamente (p. ej., información recibida de reguladores, información enviada para auditoría
propósitos, etc.).
Un sistema de información y comunicación, como un sistema de información contable (AIS),
debe implementarse para permitir la captura e intercambio de la información necesaria, así
Página 189
como conducir, administrar y controlar las operaciones de la empresa. Los AIS deben recopilar, registrar,
procesar, almacenar, resumir y comunicar información sobre una organización. Esto incluye
comprender cómo se inician las transacciones, se capturan los datos, se accede a los archivos y se actualizan,
se procesan los datos y se reporta la información. Los AIS también incluyen comprender la contabilidad
registros y procedimientos, documentos de respaldo y estados financieros.
Supervisión
Las actividades de monitoreo, ya sea de forma continua o separada, deben ocurrir para asegurar que el
El sistema de información y comunicación (es decir, AIS) se implementa de manera efectiva y, lo más importante
tantly, funciona según lo diseñado. Evaluaciones de seguimiento continuo que se han incorporado
Los procesos comerciales existentes en varios niveles, por ejemplo, proporcionan información oportuna y relevante.
información que respalda si el AIS funciona o no como se esperaba. Monitoreo de evaluaciones que son
realizadas por separado varían en alcance y frecuencia, y se llevan a cabo dependiendo de la eficacia
son, los resultados de las evaluaciones de riesgos y las metas y objetivos de gestión específicos.
Ejemplos de actividades de seguimiento pueden incluir la realización de auditorías internas o control interno.
evaluaciones; evaluar para una supervisión eficaz; seguimiento contra presupuestos establecidos y aprobados
obtiene; rastrear software comprado y dispositivos móviles; la realización periódica externa, interna y /
o auditorías de seguridad de la red; trayendo a bordo de un Oficial de Seguridad Jefe de Información y forense
especialistas ; instalar software de detección de fraudes ; e implementar una línea directa de fraude , entre otros.
Deficiencias, si las hay, que resultan de las actividades de seguimiento y evaluaciones con respecto a los criterios
establecidos
lizados por lapor reguladores
gerencia, debenyser
organismos que establecen
documentados, evaluadosnormas, así como políticas
y comunicados. y procedimientos
Las deficiencias son establecidos
comunicados a la dirección y al Consejo, según proceda.
La evaluación de riesgos constituye el primer paso en la metodología de gestión de riesgos. Evaluaciones de riesgo, basadas
en NIST, son utilizados por las organizaciones para determinar el alcance de las amenazas potenciales y evaluar
los riesgos asociados con los sistemas de TI. Los resultados de lo anterior ayudan a la gerencia a identificar
implementar e implementar controles de TI apropiados para reducir y / o eliminar esas amenazas y
riesgos. Las evaluaciones de riesgos proporcionan un marco para la asignación de recursos para lograr los máximos benefici
Dada la cantidad significativa de áreas de TI, pero la cantidad limitada de recursos, es importante concentrarse
en las áreas correctas. Las evaluaciones de riesgos son tanto una herramienta como una técnica que se pueden utilizar para a
el nivel de riesgo de un determinado proceso o función, como TI. Representan una forma de aplicar obje-
medición positiva a un proceso que es realmente subjetivo.
Un director de riesgos (CRO) , en colaboración con la Junta Directiva (Junta), debe
determinar los límites de riesgo que la organización está dispuesta a asumir. Estos límites de riesgo no deben ser estáticos
pero debe estar sujeto a cambios: un documento de trabajo. Estos límites de riesgo deben publicarse y
disponible para las unidades de negocio, ya que cada director de negocio será responsable de evaluar
los riesgos de la línea de negocio, creando un plan de acción de riesgos y determinando si sus riesgos se encuentran dentro o
fuera de las tolerancias establecidas.
Como parte del proceso de planificación estratégica de cada año, los gerentes comerciales deben
completar una evaluación de riesgos de su área. Incluido en eso es una evaluación de riesgo del negocio
riesgos de cada aplicación o sistema que posee la línea de negocio. COBIT o estándares similares
como NIST, la Organización Internacional de Normalización / Electro Técnico Internacional
Página 190
Comisión (ISO / IEC), y otros deben acordarse como la guía que se utilizará. Esta voluntad
colocar todas las evaluaciones de riesgos de TI en términos similares y estandarizarlas un poco en cuanto a
tipos de riesgos identificados.
Las evaluaciones de riesgo deben ser completadas por la línea de negocio con la ayuda del riesgo de TI.
coordinador de gestión o auditoría interna. El coordinador de gestión de riesgos de TI puede brindar información
e información a la línea de negocio con respecto a los riesgos específicos que enfrenta la aplicación o
sistema. El gerente comercial podría evaluarlos a la luz del riesgo general que enfrenta el
línea de negocio. El departamento de TI debe realizar las evaluaciones de riesgo de las aplicaciones en toda la empresa.
ciones y sistemas como la red o el software de correo electrónico para toda la empresa. El departamento de TI,
encabezado por el director de tecnología (CTO) , estaría evaluando, gestionando y aceptando
los riesgos asociados con este tipo de tecnología empresarial.
De alguna manera, el CRO y el personal de la CTO servirán como facilitadores de este proceso. Ellos
determinará si la evaluación de riesgos no es adecuada o carece de información. Ellos crearán herramientas
ayudar a la línea de negocio en la identificación de riesgos y posibles controles, decidiendo qué controles
implementar, monitorear y medir la efectividad de esos controles.
Una vez completada la evaluación de riesgos y todos los riesgos a los que se enfrenta la línea de negocio en particular,
completamente identificado, el gerente comercial, con la ayuda del personal del CRO, debe revisar el
riesgos y controles asociados. Estos deben compararse con los requisitos reglamentarios aplicables.
y límites aprobados por la Junta para asumir riesgos. Si algún riesgo queda fuera del ámbito regulatorio o de la Junta
límites, el CRO y la dirección empresarial trabajan juntos para encontrar soluciones para reducir los riesgos
a niveles aceptables. Esto podría incluir implementar más controles, por ejemplo, requerir dos
firmas de administración antes de procesar un cambio de archivo maestro. Podría incluir la compra de seguros
para transferir parte del riesgo a un tercero, como un seguro contra riesgos para el centro de
desastres naturales iban a golpear. O podría significar decidir no ofrecer un servicio en particular, como
abrir cuentas en línea, debido a un riesgo de fraude inaceptablemente alto. Todas estas posibles soluciones
resultar en la reducción del riesgo, y el objetivo es reducir el riesgo a un nivel aceptable tanto para el
agencias reguladoras de la organización y su Junta.
Las evaluaciones de riesgo deben revisarse y reconsiderarse cada año. Esta revisión debe incluir
agregar nuevos riesgos a la unidad de negocios debido a nuevos productos o servicios, o tal vez una nueva tecnología
nología que se acaba de implementar. La revisión también debe evaluar si las calificaciones de cada
el riesgo estaba justificado o puede ser necesario ajustarlo. La organización puede decidir solicitar una revisión
de la evaluación de riesgos con mayor frecuencia al comienzo de la implementación hasta que esté satisfecho
Todos los riesgos potenciales han sido identificados e incluidos en el proceso de gestión de riesgos. El CRO
también debe implementar un cuadro de mando y métricas, como un modelo de madurez, contra el cual la línea
de la gestión de riesgos empresariales se puede medir. Líneas de negocio con buena gestión de riesgos
las prácticas deben ser recompensadas.
Auditoría interna evaluará de forma independiente las evaluaciones de riesgo cada vez que audite una función,
área o aplicación. Si la auditoría considera que las evaluaciones de riesgos no son adecuadas o que todos los
los riesgos no se han identificado o controlado adecuadamente, sería un problema tanto para el negocio
y el CRO. Las auditorías periódicas por parte de auditores externos y organismos reguladores también son una parte necesar
del programa de gestión de riesgos de TI.
Orientación disponible
Existen varios estándares profesionales que brindan orientación a los auditores y gerentes involucrados
en el proceso de evaluación de riesgos. Estos estándares provienen de organizaciones ampliamente reconocidas como
Página 191
COBIT y la ISO / IEC. Otros estándares para evaluaciones de riesgo están disponibles en NIST, GAO,
Instituto Americano de Contadores Públicos Certificados, ISACA, Instituto de Auditores Internos y
el Comité de Organizaciones Patrocinadoras de la Comisión Treadway.
COBIT
Como se dijo anteriormente, COBIT es un marco de gobierno de TI bien conocido que ayuda a las organizaciones
ciones en las áreas de cumplimiento normativo y alineación de la estrategia de TI y la organización
metas. COBIT también es crucial para las organizaciones en el área de gestión de riesgos. Específicamente,
El conjunto internacional de COBIT de prácticas de TI generalmente aceptadas u objetivos de control ayudan a emplear
ees, gerentes, ejecutivos y auditores en: comprensión de los sistemas de TI, descarga fiduciaria
responsabilidades, gestionar y evaluar los riesgos de TI y decidir los niveles adecuados de seguridad y
control S.
COBIT ayuda a las organizaciones a crear un valor óptimo de TI manteniendo un equilibrio entre
obteniendo beneficios y optimizando los niveles de riesgo y el uso de recursos. El marco es valioso para todos los tamaños.
tipos de organizaciones, incluidas las comerciales, sin fines de lucro o del sector público. El completo
El marco global proporciona un conjunto de objetivos de control que no solo ayuda a la gestión y el gobierno de TI
Los profesionales de las finanzas gestionan sus operaciones de TI, pero también los auditores de TI en sus búsquedas de
esos objetivos. La selección de COBIT puede ser apropiada cuando el objetivo de la organización no es
solo para comprender y alinear los objetivos comerciales y de TI, sino también para abordar las áreas de regulación
cumplimiento y gestión de riesgos.
ISO / IEC
La familia de normas ISO / IEC 27000 incluye técnicas que ayudan a las organizaciones a asegurar sus
activos de información. ISO / IEC 27005: 2011 Tecnología de la información — Técnicas de seguridad—
La gestión de riesgos de seguridad de la información, por ejemplo, proporciona pautas para la
gestión de riesgos de seguridad de la información. Es compatible con los conceptos generales especificados en ISO /
IEC 27001, y se aplica a organizaciones dentro de la mayoría de los tipos de industrias (por ejemplo, comercial /
vate, gobierno, sin fines de lucro, etc.). ISO / IEC 27005: 2011 y el resto de la familia
de las normas ISO / IEC todas ayudan a las organizaciones a gestionar la seguridad de los activos, incluidos, pero no
limitado a, información financiera, propiedad intelectual, detalles de los empleados o información confiada
por terceros.
La norma ISO / IEC 27005: 2011 no especifica ni recomienda ningún control de riesgo específico.
método de gestión, pero sugiere un proceso que consiste en una secuencia estructurada de
actividades, que incluyen:
◾ Establecer el contexto de gestión de riesgos, incluido el alcance, los objetivos de cumplimiento,

enfoques / métodos que se utilizarán, y políticas y criterios relevantes (p. ej., riesgo de la organización
tolerancia, apetito por el riesgo, etc.).
◾ Evaluar los riesgos de información cuantitativa o cualitativamente relevantes considerando información
activos, amenazas, vulnerabilidades y controles existentes. Esta evaluación será útil para
determinar la probabilidad de incidentes o escenarios de incidentes, y el negocio previsto
consecuencias si ocurrieran (es decir, nivel de riesgo).
◾ Determinar, con base en el nivel de riesgo, cómo reaccionará la gerencia o responderá a los
riesgos (es decir, si la administración evitará por completo, reducirá, transferirá a un tercero o
finalmente acepta el riesgo).
Página 192
◾ Mantener a las partes interesadas conscientes e informadas a lo largo del riesgo de seguridad de la información.
proceso de gestión.
◾ Seguimiento y revisión de riesgos, tratamientos de riesgos, objetivos de riesgo, obligaciones y criterios.
continuamente.
◾ Identificar y responder adecuadamente a cambios significativos.
Instituto Nacional de Estándares y Tecnología (NIST)

Un enfoque principal de las actividades del NIST en TI es proporcionar criterios de medición para respaldar el desarrollo
de tecnología fundamental y con visión de futuro. Normas y directrices del NIST se emiten como Federal
Estándares de procesamiento de información (FIPS) para uso en todo el gobierno. NIST desarrolla FIPS cuando
Existen requisitos obligatorios del gobierno federal para los estándares de TI relacionados con la seguridad y
interoperabilidad y no existen estándares o soluciones industriales aceptables.
Uno de los primeros de varios estándares federales emitidos por NIST en 1974 fue FIPS 31, “Guidelines
para el procesamiento automático de datos, seguridad física y gestión de riesgos ". Este estándar proporcionó
la guía inicial para las organizaciones federales en el desarrollo de la seguridad física y la gestión de riesgos
programas para instalaciones de sistemas de información (SI). Luego, en marzo de 2006, NIST emitió FIPS 200
"Requisitos mínimos de seguridad para la información y los sistemas de información federales", donde se
Las agencias generales eran responsables de incluir dentro de su información “políticas y procedimientos que
garantizar el cumplimiento de los requisitos de configuración del sistema mínimamente aceptables, según se determine
por la agencia ".
La gestión de las configuraciones del sistema también es un requisito mínimo de seguridad identificado en FIPS
200 y NIST SP 800-53, “Controles de seguridad y privacidad para sistemas de información federales
y organizaciones ”, llegó a definir controles de seguridad y privacidad que respaldaban este requisito.
ment. En agosto de 2011, NIST publicó SP 800-128, "Guía para la configuración centrada en la seguridad
Gestión de SI ". Conceptos y principios de gestión de la configuración descritos en este especial
La publicación proporcionó información de respaldo para NIST SP 800-53, y cumplió con los
Management Framework (RMF) que se analiza en NIST SP 800-37, “Guía para aplicar la
Marco de gestión de riesgos para los sistemas de información federales: un enfoque de ciclo de vida de seguridad ”,
según enmendado. Directrices más específicas sobre la implementación del paso de monitoreo del MGR son
proporcionado en el Borrador NIST SP 800-137, “Monitoreo continuo de seguridad de la información para
SI y Organizaciones ". El propósito del NIST SP 800-137 en el RMF es continuamente
monitorear la efectividad de todos los controles de seguridad seleccionados, implementados y autorizados para
proteger la información organizacional y el SI, que incluye la seguridad de gestión de la configuración
controles identificados en SP 800-53. Estos documentos son un muy buen punto de partida para comprender
la base y muchos enfoques que se pueden utilizar para evaluar el riesgo en TI hoy.
Al evaluar los riesgos relacionados con TI, se debe prestar especial atención a NIST SP 800-30
guía, "Guía para realizar evaluaciones de riesgos". * La guía NIST SP 800-30 proporciona una
base común para el personal de las organizaciones con o sin experiencia, que utilizan o apoyan
portar el proceso de gestión de riesgos para sus sistemas de TI. El personal de las organizaciones incluye: senior
gerencia, gerentes de seguridad de TI, personal de soporte técnico, consultores de TI y auditores de TI,
entre otros. El estándar de evaluación de riesgos del NIST SP 800-30 se puede implementar en
múltiples sistemas interrelacionados, desde organizaciones pequeñas a grandes.
Página 193
Las pautas del NIST, incluida la SP 800-30, han ayudado a las agencias y organizaciones federales a
mejorando significativamente su calidad general de seguridad de TI al:
◾ proporcionar un marco estándar para gestionar y evaluar los riesgos de SI de las organizaciones,
apoyar misiones organizacionales y funciones comerciales;
◾ permitir la toma de determinaciones basadas en el riesgo, garantizando al mismo tiempo implementaciones rentables;
◾ describir un enfoque más flexible y dinámico que se puede utilizar para monitorear la información
estado de seguridad de la información de los SI de las organizaciones;
◾ Apoyar un enfoque de abajo hacia arriba en lo que respecta a la seguridad de la información, centrado en
SI individuales que apoyan a la organización; y
◾ promover un enfoque de arriba hacia abajo relacionado con la seguridad de la información, centrándose en
Problemas relacionados con las TI desde una perspectiva corporativa.
Las organizaciones dentro del sector privado (pequeñas, medianas y grandes) están utilizando significativamente NIST
directrices para promover funciones comerciales críticas seguras, incluida la confianza de los clientes en
la capacidad de las organizaciones para proteger su información personal y confidencial. Además, el flex-
La posibilidad de implementar las pautas del NIST proporciona las herramientas apropiadas de la organización para demostr
cumplimiento de las normas.
El estándar NIST SP 800-30 se utiliza con frecuencia al realizar evaluaciones de riesgo porque
de su flexibilidad y facilidad de uso para: (1) identificar riesgos potenciales asociados con SI, así como
(2) determinar la probabilidad de ocurrencia, impacto y salvaguardas adicionales para la mitigación.
La directriz ha demostrado llevar a cabo evaluaciones precisas y exhaustivas de riesgos y vulnerabilidades.
vínculos con respecto a la confidencialidad, integridad y disponibilidad de la información. El Apéndice 5 muestra un
ejemplo de una evaluación de riesgos de TI realizada para una organización que utiliza NIST SP 800-30.
Oficina de Responsabilidad del Gobierno (GAO)

La GAO es una agencia no partidista dentro de la rama legislativa del gobierno. La GAO con-
realiza auditorías, encuestas, investigaciones y evaluaciones de programas federales. Esto puede incluir auditorías
de agencias federales y gobiernos estatales, del condado y de la ciudad, y se extienden a la industria privada, donde
se gastan los fondos federales. A menudo, el trabajo de la GAO se realiza a pedido de un comité del Congreso.
tees o miembros, o para cumplir con requisitos legislativos específicos o básicos. Los GAO
Los hallazgos y recomendaciones se publican como informes a los miembros del Congreso o se entregan
como testimonio a los comités del Congreso. La GAO ha publicado numerosos informes en computadora
seguridad, vulnerabilidades de TI y evaluaciones de riesgos.
El gobierno federal de los Estados Unidos ha invertido una cantidad extraordinaria de recursos en
iningir riesgo que se remonta a principios de la década de 1960. Ejemplos de estos incluyen contabilidad gubernamental
Estándares (GAS) y los informes de Tecnología y Gestión de la Información (IMTEC) de la GAO. GAS
4.29, “Controles de protección”, por ejemplo, se utiliza para ayudar a los auditores a reconocer los factores de riesgo que inv
procesamiento informático. IMTEC 8.1.4, “Tecnología de la información: una guía de auditoría para evaluar
Riesgo de adquisición ”, se utiliza en la planificación y realización de evaluaciones de riesgo de hardware y
Adquisiciones de software, telecomunicaciones y desarrollo de sistemas.
Instituto Americano de Contadores Públicos Certificados (AICPA)

Las Declaraciones sobre Normas de Auditoría (SAS) son emitidas por la Junta de Normas de Auditoría del
AICPA y se reconocen como interpretaciones de las 10 normas de auditoría generalmente aceptadas. Como
Página 194
mencionado en capítulos anteriores, el AICPA ha jugado un papel importante en la emisión de orientación para
la profesión contable y de control. Un ejemplo en la aplicación de los conceptos de materialidad y riesgo de auditoría
viene con la emisión de SAS 47, "Riesgo de auditoría e importancia relativa en la realización de una auditoría", que
se relaciona con la evaluación de riesgos. En SAS 47, el riesgo de control se define como la posibilidad de una incorrección
que ocurren en un saldo de cuenta o clase de transacciones que (1) podrían ser materiales cuando se agregan
con errores en otros saldos o clases y (2) no se evitarán ni se detectarán en un
oportunamente por el sistema de control interno.
SAS 65, “La consideración del auditor de la función de auditoría interna en una auditoría de
Declaraciones ”, requiere que, en todos los trabajos, el auditor desarrolle algún entendimiento de los
función de auditoría interna (auditoría de TI, si está disponible) y determinar si esa función es relevante para
la evaluación del riesgo de control. Por tanto, si existe una función de auditoría interna, se debe evaluar. los
la evaluación no es opcional. En 1996, la AICPA emitió SAS 80, que enmendó SAS 31, "Evidential
Importar." SAS 80 tenía como objetivo directo mejorar la auditoría en el entorno de TI. Este SAS hizo
un profundo impacto en la profesión de auditoría. Un extracto de SAS 80 dice: “En entidades donde
La información significativa se transmite, procesa, mantiene o accede electrónicamente, el audi-
tor puede determinar que no es práctico o posible reducir el riesgo de detección a un nivel aceptable
realizando solo pruebas sustantivas para una o más afirmaciones de los estados financieros. Por ejemplo,
la posibilidad de que se produzca una iniciación o alteración inadecuada de la información y que no se detecte
ser mayor si la información se produce, mantiene o accede sólo en forma electrónica. De tal
circunstancias, el auditor debe realizar pruebas de controles para reunir material probatorio para usar en
evaluar el riesgo de control, o considerar el efecto en su informe ".
SAS 94, “El efecto de la tecnología de la información en la consideración del auditor de
Control en una auditoría de estados financieros ”, se adoptó en 2001 y proporcionó orientación a los auditores.
sobre el efecto de la TI sobre el control interno y sobre la comprensión del auditor del control interno
y evaluación del riesgo de control. SAS 109, “Comprensión de la entidad y su entorno y
Evaluación de los riesgos de incorrección material ”, fue adoptado en 2006 y también enfatizó la
conocimiento del auditor de la entidad para validar y verificar cómo contribuye TI al riesgo de material
incorrección real y si existen controles para prevenir o detectar errores o fraude.
ISACA
ISACA (anteriormente conocida como la Asociación de Control y Auditoría de Sistemas de Información) es un
amplia asociación sin fines de lucro de más de 28,000 profesionales dedicados a auditoría, control,
y seguridad en más de 100 países. La Fundación de Auditoría y Control de Sistemas de Información es una
Fundación asociada sin fines de lucro comprometida con la expansión de la base de conocimientos de la profesión.
a través de un compromiso con la investigación. La junta de estándares de ISACA ha actualizado y publicado varios
Directrices de auditoría de sistemas de información que han sido reconocidas como normas de auditoría de sistemas.
La directriz de ISACA titulada "Uso de la evaluación de riesgos en la planificación de auditorías" especifica el nivel
del trabajo de auditoría necesario para cumplir un objetivo de auditoría específico; es una decisión subjetiva tomada por el
Auditor de TI. El riesgo de llegar a una conclusión incorrecta basada en los hallazgos de la auditoría (riesgo de auditoría)
es un aspecto de esta decisión. El otro es el riesgo de que ocurran errores en el área auditada.
(riesgo de error). Las prácticas recomendadas para la evaluación de riesgos al realizar auditorías financieras están bien
documentado en las normas de auditoría para auditores financieros, pero se requiere orientación sobre cómo aplicar
tales técnicas a las auditorías de TI.
La gerencia también basa sus decisiones en cuánto control es apropiado después de la evaluación de
el nivel de exposición al riesgo que está dispuesto a aceptar. Por ejemplo, la incapacidad de procesar la computadora
aplicaciones durante un período de tiempo es una exposición que podría resultar de inesperados e indeseables
Página 195
eventos (por ejemplo, incendio del centro de datos, inundaciones, etc.). Las exposiciones pueden reducirse mediante la imple
de controles diseñados apropiadamente. Estos controles se basan normalmente en la estimación de la
ocurrencia de eventos adversos y están destinados a disminuir dicha probabilidad. Por ejemplo, un incendio
La alarma no previene incendios, pero está destinada a reducir el alcance de los daños por incendio.
La guía de ISACA proporciona una guía para la aplicación de los estándares de auditoría de TI. El auditor de TI
debe considerar dicha orientación al determinar cómo lograr la implementación de los
normas de aplicación, utilice el juicio profesional en su aplicación y esté preparado para justificar cualquier
salida.
Instituto de Auditores Internos (IIA)

Establecido en 1941, el IIA sirve a más de 85.000 miembros en auditoría interna, gobernanza
y control interno, educación en auditorías de TI y seguridad en más de 120 países.
El IIA cuenta con la Norma de Desempeño 2110 titulada "Gestión de Riesgos", que especifica
Afirma que la actividad de auditoría interna debe ayudar a la organización identificando y evaluando
exposiciones significativas al riesgo y contribuir a la mejora de la gestión de riesgos y
sistemas de control. Proporciona orientación adicional en forma de Norma de implementación 2110.A1
(Encargos de aseguramiento) con los que la actividad de auditoría interna debe monitorear y evaluar
eficacia del sistema de gestión de riesgos de la organización. Estándar de implementación 2110.A2
(Encargos de aseguramiento) estipula que la actividad de auditoría interna debe evaluar las exposiciones al riesgo.
relacionados con el gobierno, las operaciones y los sistemas de información de la organización con respecto a:
◾ Fiabilidad e integridad de la información financiera y operativa

◾ Efectividad y eficiencia de las operaciones
◾ Salvaguarda de activos
◾ Cumplimiento de leyes, regulaciones y contratos
El último estándar de desempeño aborda los compromisos de consultoría en el Estándar de implementación

2110.C1 (Contratos de consultoría). El IIA recomienda que durante los trabajos de consultoría,
Los auditores internos deben abordar el riesgo de manera consistente con los objetivos del trabajo y estar alerta a
la existencia de otros riesgos significativos.
El IIA también ha desarrollado una serie de publicaciones que ayudan en la evaluación de los
controla la información financiera, en particular los controles de TI. Estos se conocen como las Guías de la
Evaluación de riesgos de TI o GAIT. GAIT para "Evaluación de la deficiencia de controles generales de TI"
es un enfoque de arriba hacia abajo y basado en riesgos para evaluar los controles generales de TI. Tal MARCHA proporcion
un enfoque para evaluar las deficiencias de los controles generales de TI identificadas durante una auditoría financiera
o evaluación de control Sarbanes-Oxley. El GAIT para "Riesgo empresarial y de TI", o GAIT-R, es un
metodología de auditoría basada en riesgos para alinear las auditorías de TI con los riesgos comerciales.
Comité de Organizaciones Patrocinadoras del

Comisión Treadway (COSO)
El COSO se formó en 1985 como una organización independiente, voluntaria y del sector privado dedicada
para mejorar la calidad de la información financiera a través de la ética empresarial, controles internos efectivos,
y gobierno corporativo. COSO está formado por representantes de la industria, la contabilidad pública
agencias, firmas de inversión y la Bolsa de Valores de Nueva York. El primer presidente de COSO fue
James C. Treadway, Jr., vicepresidente ejecutivo y consejero general de Paine Webber Inc. en el
Página 196
Time y ex comisionado de la Comisión de Bolsa y Valores de EE. UU. por lo tanto, la

nombre Comisión Treadway.
El Marco Integrado de ERM de COSO, discutido anteriormente, fue desarrollado por el
de contabilidad, PriceWaterhouseCoopers, y publicado en septiembre de 2004. ERM — Integrated
El marco es una herramienta eficaz para que la alta dirección y la Junta establezcan objetivos y estrategias;
identificar, evaluar y gestionar áreas de riesgo; Seleccionar e implementar controles para mitigar o abordar el
áreas de riesgo; y garantizar que la empresa logre finalmente sus objetivos y metas. El ERM—
El modelo de Marco Integrado se ilustra en el Cuadro 6.1.
El seguro como parte de las evaluaciones de riesgos de TI

Las evaluaciones de riesgo relacionadas con las operaciones de TI también incluyen seguros. Una clara comprensión de
La gestión de seguros y riesgos es necesaria para revisar la idoneidad del seguro de TI de una organización.
ance. Los administradores de gestión de TI y seguridad de datos deben conocer la relación entre
riesgo y seguro para comprender las razones detrás de las opciones de seguro y los tipos de seguro
que son más aplicables al entorno de TI. Esto proporciona una descripción general de las razones y
los métodos de análisis de riesgos, las alternativas de seguro y qué buscar en la cobertura de seguros de TI.
La necesidad de esta revisión se hace evidente debido a virus informáticos, ataques de denegación de servicio,
y así sucesivamente, lo que puede costar oportunidades perdidas. Las empresas deben tener una forma de protegerse
y recuperar sus pérdidas.
El seguro distribuye las pérdidas de modo que se difunda una pérdida devastadora para un individuo o empresa
equitativamente entre un grupo de asegurados. El seguro no previene la pérdida ni reduce su costo;
simplemente reduce el riesgo. El riesgo es la posibilidad de una desviación adversa de un resultado deseado
(por ejemplo, la posibilidad de morir antes de cumplir los 72 años, una interrupción en las operaciones comerciales, una
sitio de comercio electrónico sobrecargado con transacciones no válidas, spam de negocios de TI , etc.). Cuando no
gestionados, se pueden asumir los riesgos que conviene asegurar y viceversa. Las pólizas de seguro a menudo
proporcionan cobertura superpuesta en algunas áreas y ninguna en otras críticas.
Riesgos de TI normalmente asegurados

En el entorno de TI, existen riesgos especiales que comúnmente son manejados por los seguros, que incluyen:
◾ Daños en equipos informáticos

◾ Costo de los medios de almacenamiento
◾ Costo de adquirir los datos almacenados en los medios
◾ Daño a forasteros
◾ Efectos comerciales de la pérdida de funciones informáticas
Los tipos de pólizas de seguro que cubren estos riesgos incluyen propiedad, responsabilidad, interrupción del negocio
seguro de fidelidad y fidelidad. Estas políticas, especialmente escritas para riesgos relacionados con TI, deben
examinar:
◾ Cobertura de hardware y equipo (es decir, red, dispositivos de almacenamiento masivo, terminales,
impresoras y unidades centrales de procesamiento).
◾ Cobertura de los medios e información almacenada en los mismos. Por ejemplo, una unidad de disco que es
destruido puede ser reemplazado a costa de una nueva unidad. Si la unidad o el dispositivo de almacenamiento masiv
Página 197
contiene información importante, el valor de la nueva unidad de reemplazo más el valor de la

la información perdida debe recuperarse.
◾ Cobertura del costo de reemplazo o reconstrucción y el costo de hacer negocios como de costumbre
(es decir, interrupción del negocio). Esto podría implicar el alquiler de tiempo en equipo equivalente de
una empresa cercana o subcontratar a un proveedor, pagando salarios de horas extra para la reconstrucción,
y trabajo de detective. En esta área, el registro de la actividad comercial electrónica diaria resulta en
Las transacciones financieras son extremadamente importantes para identificar la interrupción o pérdida del negocio d
spam o robo de información.
◾ Cobertura de elementos tales como daños a los medios por imanes, daños por cortes de energía
(apagón) o corte de energía (apagón) y daños por falla del software.
Seguro cibernético
Los intentos de dañar o destruir sistemas informáticos (también conocidos como ciberataques) son comunes en la actualidad
en las organizaciones y puede resultar en pérdidas significativas. Por ejemplo, en 2014, el Centro de Estrategias
e International Studies estimaron que los costos anuales del delito cibernético oscilan entre $ 375 mil millones
y $ 575 mil millones para organizaciones medianas y grandes. Otro estudio realizado por Symantec en 2016
(y documentado como parte de su Informe de amenazas a la seguridad en Internet) indicó que el 43% de todo 2016
los ataques se dirigieron a pequeñas empresas (es decir, organizaciones con menos de 250 empleados). Organizaciones
debe decidir si el seguro cibernético es ahora una opción viable para mitigar tales pérdidas y sus resultados-
ing costos excesivos.
Por lo general, el seguro cibernético está excluido de la responsabilidad general comercial tradicional
pólizas, o no definidas específicamente en productos de seguros tradicionales. Una póliza de seguro cibernético (o
seguro de riesgo cibernético) se refiere a un producto de seguro diseñado para proteger organizaciones e
personas de los riesgos relacionados con la infraestructura y las actividades de TI (por ejemplo, violaciones de seguridad rela
Riesgos basados en Internet, etc.). El ciberseguro comenzó a ganar popularidad en 2005, con el valor total de
Se prevé que las primas alcancen los 7.500 millones de dólares en 2020. Según PriceWaterhouseCoopers, aproximadamente
un tercio de las empresas estadounidenses adquieren actualmente algún tipo de seguro cibernético.
Este tipo específico de seguro cubre los gastos relacionados con pérdidas propias o reclamaciones de terceros.
La cobertura generalmente incluye:
◾ pérdidas por destrucción de datos, extorsión, robo, piratería y ataques de denegación de servicio
◾ pérdidas a terceros causadas por errores y omisiones, falta de protección de datos o difamación
Antes del ciberseguro, la mayoría de las organizaciones no informaban necesariamente el impacto total de sus
violaciones de la seguridad de la información con el fin de evitar publicidad negativa y dañar la confianza de sus
clientes. Ahora deben considerar seriamente agregar seguros cibernéticos a sus presupuestos, especialmente,
si almacenan y mantienen información del cliente, recopilan información de pago en línea o simplemente
utilizar la nube para cumplir las metas y los objetivos comerciales. Debido a que los riesgos cibernéticos cambian con tanta f
Debe existir una cobertura adecuada de dichos riesgos de TI. Sin embargo, ¿qué pasa si los riesgos de TI no se pueden asegu
Reducción y retención de riesgos

Los riesgos que no son asegurables se pueden gestionar de otras formas: reducidos o retenidos. Solo porque un
El riesgo es asegurable no significa que el seguro sea la única forma de manejarlo. La reducción del riesgo puede ser
logrado mediante la prevención y el control de pérdidas. Si se puede prevenir la posibilidad de pérdida, el
se elimina el riesgo; incluso reducir la posibilidad de que ocurra la pérdida es una mejora significativa.
Página 198
Si no se puede reducir la posibilidad, a menudo se puede controlar al menos la gravedad de la pérdida. El reduc-
Este método se utiliza con frecuencia con los seguros para reducir las primas. Ejemplos de preguntas
que llevan a determinar si se pueden reducir los riesgos de TI incluyen:
◾ ¿Existe un plan completo y actualizado de recuperación ante desastres o un plan de continuidad empresarial?
◾ ¿Qué esfuerzos se han realizado para comprobar que ambos planes son viables?
◾ ¿Hay copias de seguridad fuera del sitio del archivo apropiado?
◾ ¿Son adecuados los procedimientos y prácticas para el control de accidentes?
◾ ¿Se han tomado medidas prácticas para controlar el impacto de un desastre?
◾ ¿La seguridad física es eficaz para proteger la propiedad y el equipo?
◾ ¿La seguridad del software es adecuada para proteger la información confidencial o sensible?
◾ ¿Se realizan verificaciones de equilibrio y control adecuadas en puntos clave del procesamiento?
◾ ¿Existen controles de control apropiados sobre las operaciones?
◾ ¿Existen verificaciones de control adecuadas durante el desarrollo y modificación de sistemas?
◾ ¿Se prueban los firewalls de red semanalmente?
◾ ¿Se han certificado los cortafuegos semestralmente?
◾ ¿Los contratos de compra o arrendamiento tienen términos y condiciones y remedios que
proteger a la empresa si hay un problema?
◾ ¿Los contratos han sido preparados por asesores legales con experiencia en TI y asuntos legales?
◾ ¿Se mantienen adecuadamente las instalaciones, el equipo y las redes?
Los riesgos no asegurables también se pueden retener dependiendo de la conciencia de la organización de los riesgos. Si
retenidos, los riesgos deben ser coherentes con los objetivos de gestión y los análisis de riesgos. La retención
El método, que a veces se denomina autoseguro, debe ser voluntario y cumplir con los
siguientes criterios:
◾ El riesgo debe distribuirse físicamente de modo que haya una distribución razonablemente uniforme de la exposición.
a pérdida en varias ubicaciones.
◾ Debe realizarse un estudio para determinar la máxima exposición a la pérdida.
◾ Se debe considerar la posibilidad de una experiencia de pérdida desfavorable y una decisión
alcanzado en cuanto a si esta contingencia debe cubrirse mediante una provisión de autoseguro
reservas.
◾ Se debe cobrar una prima contra las operaciones que sean adecuadas para cubrir pérdidas y
cualquier incremento de reservas que parezca aconsejable.
Muchas empresas, sin embargo, retienen los riesgos sin estimar pérdidas futuras o reservar fondos para pagar
por estas pérdidas. Las empresas deben gestionar y evaluar cuidadosamente sus riesgos de pérdidas significativas en
para proteger sus intereses comerciales.
Conclusión
Las organizaciones han reconocido el beneficio de protegerse a sí mismas de todo tipo de riesgo potencial
exposiciones. La protección proviene de una gestión y evaluación eficaces de los riesgos identificados. Riesgo
La gestión se refiere al proceso de identificación y evaluación de riesgos, seguido de la implementación de la
procedimientos o controles necesarios para reducir dicho riesgo a niveles aceptables. Un ejemplo de gestión de riesgos
La herramienta de gestión es ERM — Integrated Framework. El marco, desarrollado por COSO, es un
Página 199
herramienta eficaz para que la alta dirección y el Directorio establezcan metas y estrategias; identificar, evaluar,
y gestionar áreas de riesgo; seleccionar e implementar controles para mitigar o abordar las áreas de riesgo; y
asegurarse de que la empresa logre finalmente sus objetivos y metas.
La evaluación de riesgos constituye el primer paso en la metodología de gestión de riesgos. Son utilizados por
organizaciones para determinar el alcance de las amenazas potenciales y los riesgos asociados con
sistemas. Las evaluaciones de riesgo deben ser completadas por la línea de negocios con la ayuda del departamento de TI.
coordinador de gestión de riesgos o auditoría interna.
Existen varios estándares profesionales de organizaciones reconocidas que brindan orientación
a auditores y gerentes involucrados en evaluaciones de riesgo. Los estándares proporcionan una calidad constante
medición si es adoptada, mantenida y respaldada por la organización. Estándares de la organización
zations, como COBIT, ISO / IEC, NIST, GAO, AICPA, ISACA, IIA y COSO, son ejemplos
que se relacionan con la evaluación de riesgos en las operaciones de TI.
Las organizaciones deben desarrollar un programa sólido de gestión de riesgos para poder determinar
adecuación de su cobertura de seguro de TI. El seguro distribuye las pérdidas de modo que una pérdida devastadora para
un individuo o negocio se distribuye equitativamente entre un grupo de miembros asegurados. Algunas de las TI
Los riesgos cubiertos por las pólizas de seguro incluyen daños al equipo informático, costo de los medios de almacenamient
el costo de adquirir los datos almacenados en los medios, y los daños a terceros, entre otros. Un tipo
de seguros contra los constantes intentos de las organizaciones de dañar o destruir su computadora
sistemas (ciberataques) se llama ciberseguro. Una póliza de seguro cibernético protege a las organizaciones
e individuos de los riesgos relacionados con la infraestructura y las actividades de TI (por ejemplo, seguridad relacionada co
infracciones, riesgos basados en Internet, etc.).
Otro paso importante en el desarrollo de un programa de gestión de riesgos eficaz es aprender los métodos
ods de retención y reducción de riesgos. Los riesgos que no son asegurables se reducen o retienen.
La reducción del riesgo se puede lograr mediante la prevención y el control de pérdidas y, por lo general, disminuye
primas de seguros. Los riesgos no asegurables también se pueden retener dependiendo de la organización
conciencia de los riesgos. Si se retienen, los riesgos deben ser coherentes con los objetivos de gestión y
análisis de riesgo. El desarrollo de un programa integral de gestión de riesgos requiere importantes
esfuerzo de todas las partes; sin embargo, una vez establecidos, los beneficios de gestionar el riesgo se vuelven invaluables.
1. Defina la Gestión de Riesgos Empresariales (ERM) de acuerdo con COSO. ¿Qué es el ERM?
Marco integrado?
2. Enumere los ocho componentes del ERM: Marco Integrado. Lista de la gestión
objetivos típicamente relacionados con el marco.
3. ¿Cómo define el NIST la gestión de riesgos? ¿Cómo protege la gestión de riesgos a la organización?
información de las amenazas informáticas?
4. Defina la evaluación de riesgos.
5. NIST es uno de los varios estándares profesionales que brindan orientación a los auditores y
gerentes involucrados en el proceso de evaluación de riesgos. ¿Cómo han ayudado las pautas del NIST
agencias y organizaciones federales para mejorar significativamente su seguridad de TI general
¿calidad?
6. Enumere y describa ejemplos de cuatro recursos para herramientas y técnicas utilizadas en la identificación
ción y evaluación de riesgos relacionados con las tecnologías de la información.
7. Explique a qué se refieren las actividades de control y describa los tipos de controles disponibles.
8. ¿Qué efecto tiene el seguro sobre el riesgo?
Página 200
9. Describa qué pólizas de seguro para riesgos relacionados con las tecnologías de la información deberían incluir o cubr
10. Discuta qué es el seguro cibernético. ¿Por qué cree que el seguro cibernético se excluye con frecuencia?
de las pólizas comerciales tradicionales de responsabilidad general, o no definidas específicamente en
productos de seguros tradicionales?
Ejercicios
1. Explique por qué el componente de entorno interno del ERM — Marco integrado es
fundamental para las organizaciones.
2. Uno de los componentes del ERM — Marco integrado es la " Identificación de eventos (o riesgos) ",
donde pueden ocurrir incidentes (es decir, eventos o riesgos) en la organización empresarial y
afectar de manera significativa sus metas, objetivos y / o estrategia. Estos incidentes se pueden identificar mediante
respondiendo a las siguientes cuatro preguntas de gestión:
a. ¿Qué puede salir mal?
segundo. ¿Cómo puede salir mal?
C. ¿Cuál es el daño potencial?
re. ¿Qué se puede hacer al respecto?
El capítulo describió un ejemplo de un escenario comercial común: un fabricante de escritorio de oficina
turer que se basa en la obtención de la madera necesaria para construir los escritorios de regiones específicas en
el Caribe.
Tarea: Identificar dos escenarios potenciales y comunes adicionales que pueden tener lugar en
un entorno empresarial. Luego, proporcione respuestas a las cuatro preguntas anteriores para buscar
incidentes que pueden afectar significativamente las operaciones y los ingresos de la empresa.
3. Resuma los estándares profesionales mencionados en el capítulo que brindan orientación a
auditores y gerentes al realizar evaluaciones de riesgos.
4. Su organización ha desarrollado recientemente criterios para un programa de gestión de riesgos. Una meta
del programa es determinar la idoneidad y eficacia del seguro de TI de la empresa
cobertura. Describa cómo un programa de gestión de riesgos eficaz puede permitir una mayor
uso eficaz de los seguros de TI.
PRESENTACIÓN DE GRUPO: EVALUACIÓN DE RIESGOS
INSTRUCCIONES: Lea y estudie el Apéndice 5: Ejemplo de evaluación de riesgos de TI utilizando

NIST SP 800-30. El Apéndice 5 incluye nueve pasos para realizar una evaluación de riesgos.
TAREA: La clase se dividirá en grupos. Los grupos presentarán y explicarán los pasos 1 a 9 de la
ejemplo de evaluación de riesgos. Su presentación será evaluada individualmente y en grupo,
cuando sea apropiado.
Otras lecturas
1. Bodin, L., Gordon, L. y Loeb, M. (2008). Seguridad de la información y gestión de riesgos. Comun.
ACM , 51 (1), 64–68.
Página 201
3. Deloitte, LLP (2014). ACL para auditores . Documento interno inédito.

4. Deloitte, LLP (2014). Documentos de trabajo de planificación de auditoría de TI . Documento interno inédito.
5. Ernst & Young. (2010). Prácticas integradas de gestión de riesgos. Diapositivas de PowerPoint no publicadas.
6. Fenz, S. y Ekelhart, A. (2010). Verificación, validación y evaluación en riesgo de seguridad de la información
administración. IEEE Secur. Privacidad , 9, 1-14.
7. Instituto de Auditores Internos. https://na.theiia.org/standards-guidance/Pages/Standards-and-Guidance-
IPPF.aspx
8. Asociación de Auditoría y Control de Sistemas de Información (ISACA). (2008). ¿Vale la pena controlar el riesgo de TI?
Definición de un paradigma de propuesta de costo-valor para la gestión de riesgos de TI, www.isaca.org/Journal/archives/
Pages / default.aspx
9. Conceptos básicos de auditoría de SI. El proceso de auditoría de los sistemas de información, http://www.isaca.org/knowledge-c
ter / itaf-is-assurance-audit- / pages / is-audit-basics.aspx (consultado en julio de 2017).
10. ISO / IEC 27005: 2011 Tecnología de la información — Técnicas de seguridad — Riesgo de seguridad de la información
Administración. Seguridad ISO 27001, www.iso27001security.com/html/27005.html
11. ISO / IEC 27005: 2011 Tecnología de la información — Técnicas de seguridad — Riesgo de seguridad de la información
Gestión, www.iso.org/standard/56742.html
12. Keblawi, F. y Sullivan, D. (2007). El caso de los estándares de seguridad NIST flexibles. Computación IEEE.
Soc. , 40 (6), 19-26.
13. Lindros, K. y Tittel, E. (2016). Qué es el seguro cibernético y por qué lo necesita. CIO, www.cio.com/
artículo / 3065655 / ciberataques-espionaje / qué-es-un-seguro-cibernético-y-por-qué-lo-necesitas.html
14. Mayo, JW (2009). Gestión de riesgos para proyectos de TI. ISACA, www.isaca.org/Groups/Professional-
Inglés / risk-management / GroupDocuments / Effective_Project_Risk_Management.pdf
15. McCafferty, J. (2016). Cinco pasos para planificar un programa de auditoría de TI eficaz . Instituto de Formación MIS,
16. Asociación Nacional de Auditores de Servicios Financieros. (2002). Gestión de riesgos empresariales , John
Wiley & Sons, Inc., Hoboken, Nueva Jersey, págs. 12-13.
6 (3), 841–849.
19. Otero, AR, Tejay, G., Otero, LD y Ruiz, A. (2012). Un seguro de información basado en lógica difusa
evaluación del control de la calidad para las organizaciones, IEEE Conference on Open Systems, Kuala Lumpur,
Malasia.
controles que utilizan funciones booleanas. En t. J. Netw. Asegurar. Apl. , 2 (4), 1–11.
21. Asociación Internacional de Gestores de Riesgos Profesionales (PRMIA) (2008). Gestión de riesgos empresariales
(ERM): Verificación del estado de las mejores prácticas globales, PRMIA, Northfield, MN.
22. Psica, A. (2007). Vigilancia de riesgos: destino por delante. Auditor interno, págs. 77–80.
Nueva York.
24. Romney, MB y Steinbart, PJ (2015). Sistemas de información contable , 13ª edición. Pearson
25. Ross, R. (2007). Gestión de riesgos de seguridad empresarial con estándares NIST. Computación IEEE. Soc. , 40 (8),
88–91. doi: 10.1109 / MC.2007.284.
27. Singleton, T. (2007). Lo que todo auditor de TI debe saber sobre los nuevos estándares de la suite de riesgos
Asociación de Auditoría y Control de Sistemas de Información. Inf. Syst. Control J. , 5, 17-20.
28. Spacey, J. (2016). Cinco tipos de tratamiento de riesgos . Simplicable, http://simplicable.com/new/risk-treatment
29. Oficina de contabilidad general de los Estados Unidos. (1999). Prácticas de evaluación de riesgos de seguridad de la informació
Organizaciones líderes , GAO de EE. UU., Washington, DC, www.gao.gov/special.pubs/ai00033.pdf
(consultado en enero de 2017).
Página 202
30. Desconocido. (2008). GAIT para la evaluación de la deficiencia de control general de TI , The Institute of Internal
31. Desconocido. (2008). GAIT para Riesgos Empresariales y de TI , Instituto de Auditores Internos, Altamonte
Springs, FL.
Página 203
Capítulo 7
Gestión de proyectos
1. Explique qué es la gestión de proyectos y enumere las mejores prácticas para una gestión de proyectos eficaz.
2. Discutir los estándares de gestión de proyectos, las autoridades principales y las metodologías con frecuencia.
usado.
3. Describa los factores clave para una gestión de proyectos eficaz.
4. Explique qué es la gestión de programas.
5. Discuta el papel del auditor en la gestión de proyectos.
6. Explique la importancia de los macrodatos en la gestión de proyectos y destaque las habilidades esenciales
necesario para que los directores de proyectos gestionen de forma eficaz proyectos de big data.
Este capítulo se centra en la gestión de proyectos, en particular las mejores prácticas, estándares y metodologías.
gies que son utilizados por los directores de programas en las organizaciones para llevar proyectos de manera eficaz y eficien
hasta el fin. Este capítulo también analiza varios factores de éxito que se deben implementar al realizar
gestión activa de proyectos y el papel del auditor en la gestión de proyectos. Temas como programa
También se discute la gestión y gestión de proyectos de big data. Gestión de proyectos de TI, para
ejemplo, se refiere a los procesos y técnicas utilizados en el desarrollo de principio a fin de software
cerámica u otros sistemas. La gestión de proyectos es uno de los controles clave tanto para los auditores como para las organ
nizaciones que garantizan la entrega de proyectos a tiempo, dentro del presupuesto y con una funcionalidad totalmente efect
Gestión de proyectos
El propósito de la gestión de proyectos es identificar, establecer, coordinar y monitorear actividades,
tareas y recursos para un proyecto que sea consistente con las metas y objetivos de la organización
ción. El control eficaz de los proyectos requiere un enfoque disciplinado de sus diversos ciclos de vida:
inicio, planificación, ejecución, seguimiento y control de proyectos y cierre. Estos cinco ciclos,
Los dominios o grupos de procesos contienen tareas, incluidos conocimientos y habilidades, que se evalúan realmente
en la Certificación Project Management Professional (PMP). En general, se relacionan con tener la
las personas adecuadas involucradas, siguiendo los procesos estándar de gestión de proyectos y utilizando un conjunto de pr
herramientas de gestión para una ejecución eficaz.
177
Página 204
COBIT reconoce la gestión de proyectos como un proceso que impacta tanto la efectividad como
la eficiencia de los sistemas de información. El proceso también involucra recursos de TI que incluyen personas,
aplicaciones, tecnología, instalaciones operativas y controles. Controles sobre la gestión de proyectos que
Satisfacer los requisitos empresariales de la organización normalmente consideran:
◾ Patrocinio de gestión empresarial del proyecto

◾ Capacidades de gestión de proyectos
◾ Participación del usuario
◾ Desglose de tareas, definición de hitos y aprobaciones de fase
◾ Asignación de responsabilidades
◾ Seguimiento riguroso de hitos y entregables
◾ Presupuestos y balance de recursos internos y externos
◾ Planes y métodos de aseguramiento de la calidad
◾ Evaluaciones de riesgos de programas y proyectos
◾ Transición del desarrollo a las operaciones
La gestión de proyectos a menudo se ha descrito como parte arte y parte ciencia. El lado del arte implica el
elemento humano, la experiencia que los gerentes de proyecto aportan al proyecto, el apoyo que pueden reunir
de su gestión y, un punto crítico, cómo los gerentes de proyecto se relacionan con la organización y
su voluntad de proporcionar el nivel adecuado de apoyo para que el proyecto tenga éxito. Muchas veces, el
La relación entre el director del proyecto y la organización no se ha construido como socio.
Acercarse. Esto puede conducir a una pérdida de productividad por parte del equipo del proyecto y debe capturarse como un
riesgo del proyecto tan pronto como se reconozca. La segunda parte de la ecuación, el lado científico, es algo
más fácil de tratar. El director del proyecto debe establecer la gobernanza y los proyectos correctos.
ect el ciclo de vida de la gestión (PMLC), e integrar estos dos elementos con el proyecto apropiado
metodología de gestión.
Los analistas de la industria de TI han hecho recomendaciones generales y específicas sobre por qué los proyectos son
exitoso. Otras organizaciones de la industria de TI han construido su propio cuerpo de conocimientos para documentar
mentar prácticas aceptables. El Grupo Gartner, por ejemplo, identifica siete mejores prácticas para una
Oficina de gestión de proyectos efectiva (PMO) que mejora la efectividad del proyecto, la cartera
y gestión de programas, así como apoyar las estrategias y metas de la organización. El siguiente
Las recomendaciones son un buen punto de partida.
1. Adquirir las personas, los conocimientos, las habilidades y los comportamientos de colaboración adecuados . Esta es
característica de una PMO altamente efectiva que permite a los gerentes de proyecto poner énfasis en la contratación
solo los recursos que mejor se adapten al proyecto.
2. Identificar y ejecutar iniciativas de gran impacto y visibilidad . El enfoque aquí está en identificar
y mejorar la ejecución de proyectos críticos y altamente visibles para atraer la atención de las partes interesadas.
titulares y garantizar su compromiso y apoyo para futuras iniciativas impulsadas por PMO.
3. Informe sobre lo que realmente le importa a la empresa . Las PMO deben comunicarse e informar
sobre el estado de proyectos, carteras y programas relevantes de forma eficaz y coherente
conducta. Dicho estado debe ser informado de manera sistemática, directa e invariable a los profesionales.
Vide el liderazgo organizacional con la información apropiada necesaria para respaldar
Toma de decisiones.
4. Construya un marco que muestre cómo la PMO se alinea con los objetivos estratégicos de la empresa . UN
marco que articula la alineación entre las PMO y la evolución continua
Los objetivos, los hitos y la dirección de la organización son esenciales para respaldar el valor de la PMO.
Página 205
Gestión de proyectos ◾ 179
5. Proporcione a los gerentes senior información simple e inequívoca . Los altos directivos son muy
gente ocupada. Las PMO deben concentrarse en proporcionarles información relevante, precisa y
información oportuna para apoyar la toma de decisiones efectiva. Este tipo de reportaje informativo
también evita la desconexión entre las expectativas y la realidad percibida.
6. Resalte los logros de las PMO . Historias exitosas de PMO, como la finalización de proyectos en
tiempo y por debajo del presupuesto y la contribución del proyecto para resolver un problema comercial importante,
entre otros, deben compartirse, alentarse y promoverse en toda la organización.
7. Desarrollar la PMO para respaldar la TI bimodal y el negocio digital . Las PMO efectivas deben continuar
reevaluar y adaptar minuciosamente su modelo de servicio, procesos y capacidades para garantizar la coherencia
con metas, objetivos, dirección y necesidades actuales de la organización. PMO que fueron
centrado en la reducción de costos y la eficiencia hace varios años, ahora puede necesitar cambiar de marcha a
flexibilidad y rapidez de entrega, por ejemplo.
Estándares de gestión de proyectos, autoridades líderes,

y metodologías
Las iniciativas estratégicas y tácticas dependen de una gestión de proyectos eficaz y eficiente.
La gestión de proyectos aplica habilidades, herramientas, técnicas y, lo más importante, conocimientos, en orden
para iniciar, planificar, ejecutar, gestionar y completar proyectos con éxito. El conocimiento está típicamente en
la forma de estándares, guías y metodologías.
La principal organización de estándares para la gestión de proyectos es la Gestión de proyectos.
Instituto (PMI). Fundada en 1969, el PMI ofrece valor a los profesionales a través de la promoción global
cacia, colaboración, educación e investigación. Los estándares mundialmente reconocidos del Instituto también
como sus certificaciones, herramientas, investigación académica, cursos de desarrollo profesional y redes
Las oportunidades de desarrollo han sido clave en el desarrollo y madurez de la gestión de proyectos.
profesión. *
Los estándares de gestión de proyectos desarrollados por el PMI o el Cuerpo de
El conocimiento (PMBOK) comprende el conocimiento de prácticas innovadoras y avanzadas dentro del
profesión de gestión de proyectos. Los estándares de PMI proporcionan pautas, reglas y
características para la gestión de proyectos, programas y carteras. Incluidos dentro del PMBOK están
como sigue:
◾ Estándares fundamentales: reflejan la profesión en constante evolución;

◾ Estándares de práctica: describa las herramientas, técnicas, procesos y / o procedimientos identificados en
el PMBOK u otros estándares fundamentales;
◾ Guías de práctica: brindan información de apoyo y asistencia al aplicar las normas del PMI.
dards; y
◾ Léxico de términos de gestión de proyectos: proporciona definiciones claras y concisas para proyectar,
términos de gestión de carteras y programas para mejorar la comprensión y la coherencia
uso de terminología.
Similar al PMI es el Instituto Australiano de Gestión de Proyectos (AIPM). El AIPM es

El organismo de servicio líder en Australia para la gestión de proyectos. Se considera un promotor, desarrollador,
* http://www.pmi.org/about/learn-about-pmi.
Página 206
y líder en gestión de proyectos de empresas, industrias y gobiernos australianos. AIPM es el

segundo miembro más grande de la Asociación Internacional de Gestión de Proyectos (IPMA). El IPMA
es otro ejemplo relevante de una autoridad líder en proyectos, programas y carteras competentes
lio gestión. IPMA, fundada en 1965, es la primera asociación de gestión de proyectos del mundo.
establecido para avanzar en los logros de la profesión de dirección de proyectos en proyectos y negocios
ness éxito. * Gracias a los esfuerzos de IPMA, las mejores prácticas de gestión de proyectos son ampliamente conocidas y
aplicado adecuadamente en todos los niveles de las organizaciones del sector público y privado. La Alianza Global
for Project Performance Standards (GAPPS), también conocido en el campo de la gestión de proyectos, es
una alianza única de gobierno, industria, asociaciones profesionales, organismos nacionales de calificación
ies e instituciones de formación / académicas que han estado trabajando juntas desde 2003. La Alianza
ayuda a los profesionales y a las organizaciones a comprender los numerosos estándares y certificaciones disponibles
capaz de orientar globalmente la gestión de proyectos. El objetivo principal de GAPPS es facilitar la
reconocimiento y transferibilidad de las normas y calificaciones de gestión de proyectos al proporcionar
la comunidad global de gestión de proyectos con una fuente confiable de información comparativa.
Otros estándares y guías de gestión de proyectos comunes incluyen:
◾ Estándar IEEE 1490-2011: Guía IEEE. Adopción del Project Management Institute
Estándar. Una guía para el PMBOK
◾ ISO 21500: 2012. Orientación para la gestión de proyectos
◾ Guía de ISO 10006: 2003. Sistemas de gestión de la calidad y directrices para la calidad
Gestión en Proyectos
El PMI define la metodología como un “sistema de prácticas, técnicas, procedimientos y reglas utilizadas
por aquellos que trabajan en una disciplina ". Los gerentes de proyecto emplean metodologías para el diseño, planificación
definición, implementación y logro de los objetivos del proyecto. Hay diferentes proyectos de gestión
Metodologías de ment para beneficiar a diferentes proyectos y organizaciones, incluyendo pero no limitado
a: Tradicional / Cascada, Ágil, Ciclo de vida de desarrollo de sistemas, Proyectos en control
Ambientes (PRINCE2), cartera, programas y gestión de proyectos, cadena / ruta crítica,
Proyectos Adaptativos, Integradores de Métodos Sostenibles (PRiSM), y el Método Cristal, entre
muchos otros. A pesar de la metodología seleccionada, los objetivos generales del proyecto, el cronograma, el costo y
Los roles y responsabilidades de los participantes aún deben ser considerados cuidadosamente. El cuadro 7.1 describe
metodologías de uso frecuente en la práctica de gestión de proyectos.
Otras metodologías de gestión de proyectos relevantes incluyen Scrum, Kanban, Extreme
Programación (XP), etc., y se tratan en un capítulo posterior.
En pocas palabras, ninguna metodología de gestión de proyectos puede cumplir los objetivos de todas las organizacione
nizaciones. Una empresa puede variar según el tipo, el tamaño, la industria, las metas y los objetivos comerciales y
muchos otros factores. Como resultado, las organizaciones deben aprender sobre estos métodos de gestión de proyectos.
odologías, cómo se utilizan y los posibles beneficios que cada método puede ofrecer. Características comunes
a tener en cuenta al seleccionar una metodología de gestión de proyectos incluyen:
◾ Metas, objetivos y dirección de la organización

◾ Valores fundamentales
◾ Restricciones del proyecto
◾ Partes interesadas del proyecto
◾ Tamaño del proyecto
* http://www.ipma.world/about/.
Página 207
Figura 7.1 Metodologías de gestión de proyectos
Proyecto
administración
Metodología Descripción
Tradicional / A menudo denominado enfoque clásico, el proyecto tradicional

Cascada La metodología de gestión funciona bien, ya que simplemente evalúa las diversas
tareas del proyecto y proporciona un proceso para gestionar y supervisar
finalización de esas tareas. En el desarrollo de software, este tradicional
El enfoque se conoce como modelo Waterfall. La cascada
metodología, construida sobre el marco del método tradicional,
incluye fases fijas y cronogramas lineales. En otras palabras, maneja
Tareas secuencialmente, desde la fase de planificación hasta el desarrollo y la calidad.
aseguramiento y finalmente a la finalización y mantenimiento del proyecto. Proyecto
Los requisitos se suelen definir al principio o en la fase de planificación.
y normalmente hay pocas o ninguna modificación a dichos requisitos o
al plan. El método Waterfall se utiliza a menudo en software a gran escala.
proyectos de desarrollo donde una planificación minuciosa y una predecible
El proceso es vital.
Proyecto ágil Ágil significa capaz de moverse rápida y fácilmente. La metodología APM es
administración utilizado en proyectos que necesitan extrema agilidad en los requisitos (por ejemplo, entregar
(APM) productos al cliente de forma rápida y continua, etc.). Enfoques de APM
sobre adaptabilidad a situaciones cambiantes y retroalimentación constante. En otra
palabras, con APM no hay un producto final claramente definido en el
etapa inicial. Esto es contrario al tradicional / cascada
metodología, que requiere requisitos detallados del producto final para
fijarse en la fase inicial. Las características clave de APM involucran a corto plazo
ciclos de entrega (o sprints), requisitos ágiles, cultura de equipo dinámica,
control de proyectos menos restrictivo y énfasis en tiempo real
comunicación. APM se usa más comúnmente en el desarrollo de software
proyectos, pero la metodología también puede ayudar a otros tipos de proyectos. los
La metodología APM suele ser una buena opción para
proyectos de software o proyectos con cronogramas de desarrollo acelerados.
Sistemas Metodología de gestión de proyectos más utilizada en el desarrollo de software.

Desarrollo proyectos que describen un proceso de planificación, creación, prueba y
Ciclo vital desplegar un sistema de información. SDLC se puede utilizar individualmente o
(SDLC) combinado con otras metodologías de gestión de proyectos con el fin de
lograr los mejores resultados. Es decir, si bien solo debería haber un proyecto
metodología de gestión destacando los procesos a seguir para
asegurar la implementación exitosa del proyecto, otras metodologías pueden
también estar en su lugar para apoyar las necesidades específicas del sistema de aplicación o
siendo considerado entregable. Por ejemplo, en un sistema de información
proyecto, una aplicación de mainframe puede seguir la metodología Waterfall
mientras que una aplicación basada en web sigue a Agile. SDLC también en gran medida
hace hincapié en el uso de documentación y tiene pautas estrictas al respecto.
( Continuacion )
Página 208
Figura 7.1 ( continuación ) Metodologías de gestión de proyectos
Proyecto
administración
PROYECTOS EN Metodología de gestión de proyectos reconocida internacionalmente aprobada, utilizada,

Revisado y con el apoyo del gobierno del Reino Unido. La metodología, también
Ambientes utilizado en el sector privado, es un enfoque basado en procesos que proporciona
(PRÍNCIPE2) organizaciones un método coherente, fácil de adaptar y escalable para la
gestión de proyectos. PRINCE2 divide los proyectos en múltiples manejables
y fases controlables, cada una con sus propios planes y procesos a seguir.
PRINCE2 asegura la justificación comercial; define la estructura de la organización para
el equipo de gestión del proyecto (por ejemplo, roles y responsabilidades); y proporciona
flexibilidad en todos los niveles del proyecto. Porque su adaptabilidad y
compatibilidad, PRINCE2 es útil para organizaciones pequeñas y grandes. Hay un
Certificación PRINCE2 que se centra en procesos y proyectos. los
La certificación es administrada en el Reino Unido por APMG-International.
Instituto de Examen y Acreditación. a Para obtener la certificación, el proyecto
El candidato a gerente debe completar una capacitación PRINCE2 de un
organización de formación, así como aprobar la Fundación PRINCE2 y
Exámenes de practicante. La certificación PRINCE2 está reconocida en el
Reino Unido, Europa y Australia, mientras que la certificación PMP es
preferido en los Estados Unidos, Canadá, Oriente Medio y Australia.
Portafolio, PPPM comprende tres disciplinas de gestión: Gestión de carteras,

Programa y Gestión de programas y gestión de proyectos. La metodología PPPM
Proyecto alinea recursos y actividades para (1) cumplir con los objetivos organizacionales
administración y estrategias; (2) aumentar el potencial de la cartera; y (3) minimizar los riesgos. PPPM
(PPPM) es utilizado por los gerentes de proyecto y PMO para analizar y administrar colectivamente
proyectos actuales o propuestos basados en numerosas características clave.
Otros posibles beneficios de la metodología PPPM incluyen:
• Orientación para establecer coherencia, transparencia y control sobre

proyectos
• Mayor valor del proyecto y probabilidad de éxito del proyecto
• Implementación de un conjunto integral de habilidades para permitir la capacitación y
educación basada en orientación estandarizada, escalable y accesible
• Mejor ejecución de programas y proyectos
• Disminución de costos y sobrecostos
Cadena crítica / La metodología CC / P define y se centra en los aspectos críticos y no críticos.

Ruta (CC / P) actividades (tareas) dentro de un proyecto para asegurar su finalización con éxito.
La criticidad se basa en el cronograma necesario para completar las tareas.
Cada proyecto tiene un cierto conjunto de elementos / requisitos básicos, llamado
cadena crítica o ruta crítica, que establecen el cronograma mínimo de un proyecto.
La metodología CC / P permite a los directores de proyectos asignar recursos a
tareas críticas y / o no críticas, y reasignarlas cuando sea necesario. Esta
La utilización eficaz y eficiente de los recursos funciona bien para proyectos que
tienen tareas que dependen unas de otras. También ayuda en
medir y priorizar tareas, proporcionando a los directores de proyecto
con una descripción bien definida de la duración del proyecto.
( Continuacion )
Página 209
Proyecto
administración
Adaptado Cuando se utiliza la metodología Adaptive, el alcance de un proyecto determinado

cambia (se adapta) a través del tiempo necesario para completar y el costo de
el proyecto ambos permanecen constantes. Mientras gestiona y ejecuta el
proyecto específico, su alcance se ajusta para lograr el máximo
valor comercial, como cuando se desbloquean nuevas ideas u oportunidades
durante el desarrollo de un proyecto. Nuevamente, los costos del proyecto y
los plazos no se ven afectados como resultado del alcance ajustado.
Proyectos La metodología de proyectos PRiSM se utiliza principalmente en bienes raíces a gran escala
integrando proyectos de desarrollo o construcción / infraestructura. Similar a PRINCE2,
Sostenible PRiSM premia a los directores de proyectos con la acreditación.
Métodos
(Prisma)
Método de cristal La metodología de gestión de proyectos de CM asigna una prioridad baja a
(CM) procesos, actividades y tareas del proyecto. La metodología se centra en cambio
sobre comunicación, interacción y habilidades de los miembros del equipo. La idea de
el CM es que al centrarse en las habilidades y los rasgos de los miembros del equipo,
los proyectos se vuelven más flexibles y únicos.
HERMES HERMES es un método de gestión de proyectos desarrollado por el gobierno federal

Método administración de Suiza. HERMES apoya la dirección,
gestión y ejecución de proyectos en el contexto de TI, la
desarrollo de servicios y productos, y el cambio de
Estructuras organizacionales. Es un método simple y claramente estructurado para
entender con un diseño modular y fácilmente ampliable.
Coste total TCM, presentado por la AACE International (antes Asociación para
administración el Avance de la Ingeniería de Costos) en la década de 1990, es una
Marco de referencia enfoque / marco para gestionar los costes a lo largo del ciclo de vida de cualquier
(TCM) organización, programa, instalación, proyecto, producto o servicio. El TCM
Marco: un enfoque integrado de la cartera, el programa y el proyecto
La gestión es un mapa de proceso estructurado y anotado que explica cada
área de práctica del campo de la ingeniería de costos en el contexto de su
relación con las otras áreas de práctica, incluidas las profesiones afines.
Programa La metodología de gestión de proyectos PERT, a menudo utilizada con el Critical

Evaluación y Chain / Path, se encuentra comúnmente en los procesos de desarrollo y
revisión fabricación. Es especialmente útil para empresas como estas que planifican
Técnica expandirse en un futuro cercano, o al menos le gustaría mantener esa posibilidad
(IMPERTINENTE) abierto. Se espera que los gerentes de proyecto diferencien entre eventos,
y medir el progreso de las actividades y tareas que se completan. Por
analizar de cerca y estimar la cantidad de tiempo que debería tomar para
cada evento para ser completado, los gerentes de proyecto pueden crear fácilmente realistas
cronogramas y presupuestos para esos aspectos del proyecto.
( Continuacion )
Página 210
Proyecto
administración
europeo La gestión del ciclo de proyectos de la Comisión Europea es la preferida

Comisión metodología de gestión de proyectos para el diseño, ejecución y
Ciclo del proyecto monitorear el progreso de los programas y proyectos financiados por el
administración Comisión Europea y de muchos otros desarrollos internacionales
instituciones.
a www.apmg-international.com/en/qualifications/prince2/prince2.aspx.
◾ Costo del proyecto

◾ Capacidad para asumir riesgos
◾ Necesidad de flexibilidad
La adopción de una metodología de gestión de proyectos es esencial para las empresas y organizaciones de hoy.
ciones. Seleccionar la metodología adecuada puede transformar la forma en que los miembros del equipo se comunican,
trabajar en tareas y lograr los hitos del proyecto.
Factores clave para una gestión eficaz de proyectos

Establecer y cumplir una metodología de gestión de proyectos proporcionará una adecuada
entorno para el proyecto, pero no garantizará su éxito. La gestión de proyectos tiene la
igualar la responsabilidad por el éxito o fracaso de cualquier proyecto a través de una planificación adecuada, recursos
gestión, supervisión y seguimiento (O&T), y el empleo eficaz de herramientas de gestión.
Obtener la certificación como PMP también ha demostrado ser útil para llevar los proyectos a un final exitoso.
Planificación
La planificación eficaz del proyecto garantiza que las tareas del proyecto se definan adecuadamente y que los recursos estén
capaz y utilizado de manera eficiente, la calidad se mantiene y el proyecto se completa a tiempo y dentro
presupuesto. Los auditores pueden ayudar revisando el plan del proyecto para asegurarse de que las tareas y los entregables
se definen con suficiente detalle, se definen los requisitos de recursos, las estimaciones de tiempo son razonables,
los recursos están disponibles en el momento adecuado y el progreso del proyecto se informa periódicamente.
Dependiendo de la organización, la planificación del proyecto puede ser formal o informal. En cualquier caso,
Se deben utilizar técnicas básicas de gestión de proyectos para garantizar que el proyecto esté bien planificado y
monitoreado efectivamente. Hay muchas herramientas disponibles para ayudar al director del proyecto a preparar un
plan de proyecto. Las herramientas de gestión de proyectos permiten al usuario definir tareas y dependencias, y realizar un s
Progreso. Un plan de proyecto debe incluir hitos intermedios y una revisión regular de los entregables del proyecto.
El objetivo de la planificación del proyecto es poder predecir la duración del proyecto, los recursos necesarios,
y costos. El director del proyecto debe establecer planes razonables estableciendo metas, estimando el
tareas a realizar, asignando personal responsable de esas tareas, prioridades, estado y tarea
duración (es decir, fechas de inicio y finalización). La figura 7.2 ilustra un ejemplo de lo que es un plan de proyecto para el
el desarrollo de una aplicación financiera puede parecer.
Página 211
Figura 7.2 Planificación del proyecto
Proyecto: Desarrollo de
Aplicación financiera
Personal
Responsable
Tarea (Iniciales) Prioridad / Estado Fecha de inicio Fecha final
OBJETIVO: Con respecto al desarrollo de una aplicación o la implementación de

modificaciones a las aplicaciones existentes, la gerencia monitorea que el proyecto cumpla con
objetivos especificados, se completa dentro del presupuesto y cumple con los requisitos de tiempo.
1. Verificar la documentación ARO Alto/ 5/10/20XX 5/10/20XX

enviado por TI Terminado
personal del departamento para
realizar un seguimiento de la
proyecto establecido
objetivos, presupuesto y
estado de finalización.
2. Corroborar GMP Medio/ 5/10/20XX 7/10/20XX
información contra el Terminado
Departamento de TI
reunión administrativa
minutos.
3. Asegúrese de que EMO Alto / Pendiente 10/10/20XX 31/10/20XX

Monitoreando y
procedimientos de evaluación
son realizados por TI
departamento
manejo durante
desarrollo de la
aplicación, o
implementación de
modificaciones a las existentes
aplicaciones.
OBJETIVO: Usuarios y otras solicitudes para el desarrollo (o modificaciones) de la aplicación

se aprueban e implementan de acuerdo con los planes y la gestión del departamento de TI
intenciones.
1. Examinar el acceso especial LRO Alto/ 5/10/20XX 10/10/20XX

solicitar formularios para verificar si Terminado
estos fueron adecuadamente
completado y firmado por
personal autorizado
que pidió,
aprobado, y
procesado los formularios.
( Continuacion )
Página 212
Figura 7.2 ( continuación ) Planificación del proyecto
Personal
Responsable
2. Verificar el departamento de TI GDO Medio/ 5/10/20XX 10/10/20XX

reunión administrativa Terminado
minutos y tenga en cuenta que el
impacto de los cambios en
hardware o software
sistemas es adecuadamente
abordado por el
departamento
técnico y
equipo de administración.
OBJETIVO: La aplicación se desarrolla o modifica y se prueba en un entorno separado de
el entorno de producción.
1. Entrevistar al departamento de TI apropiado ARO Alto/ 10/10/20XX 15/10 / 20XX

personal con respecto al Terminado
Nueva aplicación
desarrollado en la prueba
medio ambiente. Verifique el
Manual de operaciones para
asegurar la consistencia
con desarrollo
procedimientos.
2. Asegúrese de que la demostración GMP Alto/ 10/10/20XX 15/10 / 20XX

los ambientes son Terminado
disponible para probar el
de nuevo desarrollo o
aplicación modificada
anterior a su
instalación en producción
medio ambiente.
3. Obtenga de la TI EMO Alto / Pendiente 10/10/20XX 15/10 / 20XX

administrativo
personal el especial
formulario de solicitud de acceso a
asegurar la adecuada
autorización para trabajar
con el nuevo o
aplicación modificada
sistema en la prueba
medio ambiente.
( Continuacion )
Página 213
Figura 7.2 ( continuación ) Planificación del proyecto
Personal
Responsable
OBJETIVO: El acceso al entorno de prueba y producción está debidamente restringido.
1. Verifique que los ID de usuario LRO Alto / Pendiente 10/10/20XX 18/10/20XX

asignado a la prueba de acceso
los entornos no son
siendo utilizado por usuarios en
entornos vivos.
2. Verifique que el acceso al GDO Alto / Pendiente 10/10/20XX 18/10/20XX

el entorno de prueba es
restringido a autorizado
personal de afectados
organización
departamentos.
3. Examinar el perfil de usuario ARO Alto / Pendiente 12/10/20XX 20/10 / 20XX

informes para verificar que solo
usuarios que realizan
tareas o usuarios especiales
que realizan prueba
los procedimientos fueron
incluido en la lista.
OBJETIVO: La administración conserva la versión anterior de la aplicación y / o los datos para permitir
recuperación del entorno de TI en caso de problemas de procesamiento.
1. Corroborar con GMP Alto / Pendiente 20/10 / 20XX 31/10/20XX

TI apropiado
personal que respalda
los procedimientos son
realizado antes de cualquier
implementación o
procedimientos de actualización
realizado para evitar
interrupción de las operaciones.
2. Confirme que una prueba ARO Alto / Pendiente 10/10/20XX 5/10/20XX

se crea el ambiente
para realizar la prueba
procedimientos previos a
implementación para vivir
ambiente de nuevo
aplicaciones y / o
modificaciones.
Página 214
Administracion de recursos
Hay muchas funciones individuales que se requieren para entregar un proyecto exitoso. El negocio
ness tiene que definir los requisitos, los desarrolladores de aplicaciones tienen que entregar el código, la calidad
El grupo de aseguramiento de la calidad y los probadores deben validar el código, y los grupos de infraestructura deben
apoyar la aplicación. Se puede asignar a un equipo de proyecto personas con diversos conjuntos de habilidades. Proyecto
las asignaciones pueden ser a tiempo completo o parcial. Los miembros del equipo pueden ser transferidos o asignados al pr
equipo. El desafío para el gerente de proyecto aquí es asegurarse de que:
◾ Existe una gobernanza adecuada.

◾ Los recursos adecuados, como dinero, personas e instalaciones, están disponibles en el momento adecuado.
◾ El proyecto tiene una estructura de desglose de obra suficientemente detallada para llevarla a cabo.
◾ Se priorizan las tareas del proyecto para evitar interferencias con las fechas de vencimiento de otros proyectos.
◾ Los entregables se producen con éxito y de manera oportuna.
◾ Se está comunicando y participando suficientemente con la dirección.
◾ El usuario final está involucrado y recibe los resultados acordados para el proyecto.
Supervisión y seguimiento
O&T ayuda a garantizar que un proyecto esté a la altura de sus compromisos. Como con todo, el mejor puesto
los planes pueden fallar debido a una mala ejecución. Se deben implementar controles para identificar los proyectos que
corriendo por el mal camino. La O&T durante todas las fases del proceso de desarrollo ayuda a asegurar que los pro-
Se siguen los ceses (o requisitos) y se mantiene el control. O&T continúa después del proyecto
se implementa para garantizar que todos los beneficios comerciales prometidos cuando se aprobó el proyecto
Los costos realizados y en curso se mantienen en línea con las estimaciones originales. El objetivo de O&T es
Proporcionar una visibilidad adecuada del progreso real para que la gerencia pueda tomar acciones efectivas.
cuando el desempeño del proyecto se desvía significativamente de los planes. Estos requisitos deben
estar documentado y controlado. La figura 7.3 ilustra una lista de verificación de muestra de la gestión de proyectos
requisitos, por sección, que se rastrean comúnmente.
Figura 7.3 Supervisión y seguimiento del proyecto
Proyecto: [Nombre del proyecto]
Sección y requisito
Metas
1. Los resultados y el rendimiento reales se comparan con los planes.
2. Se toman y gestionan acciones correctivas hasta el cierre cuando los resultados reales y
el desempeño se desvía significativamente de los planes.
3. Todos los cambios a los compromisos son acordados por los grupos o partes afectados.
Compromisos
1. El gerente de proyecto está designado para ser responsable de las actividades y los resultados del proyecto.
( Continuacion )
Página 215
Figura 7.3 ( Continuación ) Supervisión y seguimiento del proyecto
2. El proyecto sigue una política organizativa documentada para gestionar proyectos de software que
incluye un plan de desarrollo de software documentado.
3. El gerente de proyecto está informado sobre el estado y los problemas del proyecto.
4. Se toman las acciones correctivas necesarias.
5. Los grupos afectados están involucrados y están de acuerdo con todos los cambios en los compromisos.
6. La alta dirección revisa todos los cambios en los compromisos.
Habilidades
1. El plan de desarrollo de software está documentado y aprobado.

2. El gerente de proyecto asigna explícitamente responsabilidades por los productos y actividades del trabajo.
3. Se proporcionan recursos y financiación adecuados para las actividades de seguimiento y supervisión.
4. El equipo directivo está capacitado.
5. Los gerentes de primera línea comprenden los aspectos técnicos del proyecto.
Ocupaciones
1. Se utiliza un plan de desarrollo documentado para rastrear las actividades del proyecto y
estado de comunicación.
2. Se documentan las revisiones del plan.
3. Los compromisos y / o cambios de compromisos, ya sean individuales o grupales, son

revisado con la alta dirección.
4. Los cambios en los compromisos se comunican a todas las personas y grupos afectados.
de acuerdo con un procedimiento documentado.
5. Se realiza un seguimiento de las estimaciones de tamaño de los productos de trabajo o los cambios en los productos de trabajo existentes.
y acción correctiva tomada cuando sea necesario.
6. Se realiza un seguimiento del esfuerzo y el costo del proyecto y se toman las acciones correctivas cuando es necesario.
7. Se realiza un seguimiento del cronograma del proyecto y los recursos informáticos críticos y se toman medidas correctivas.
cuando sea necesario.
8. Se realiza un seguimiento de las actividades técnicas y se toman acciones correctivas cuando es necesario.
9. Se hace un seguimiento de los riesgos y se toman medidas correctivas cuando es necesario.
10. Se registran los datos reales de medición y replanificación.
( Continuacion )
Página 216
Figura 7.3 ( Continuación ) Supervisión y seguimiento del proyecto
11. Se llevan a cabo revisiones internas periódicas para seguir el progreso técnico, los planes, el desempeño,
y problemas contra el plan.
12. Se realizan revisiones formales en hitos seleccionados del proyecto de acuerdo con un documento
procedimiento.
Mediciones
1. Las mediciones se diseñan y utilizan para supervisar la gestión de todo el seguimiento y

actividades de supervisión.
Veri cación
1. Las actividades de gestión se revisan periódicamente con la dirección senior y de proyectos.

2. El equipo de aseguramiento de la calidad audita la gestión de las actividades de planificación e informa
resultados de dicha auditoría.
Fuente: Adaptado de Senft, S., Gallegos, F. y Davis, A. 2012. Control de tecnologías de la información
y Auditoría . Boca Ratón: CRC Press / Taylor & Francis.
Herramientas de gestión de proyectos

La gestión eficaz de proyectos requiere el uso de una gestión de proyectos independiente y en toda la empresa.
herramientas de ment. Para el desarrollo y seguimiento de proyectos en toda la empresa, por ejemplo, hay varios
funciones que se pueden automatizar e integrar como:
◾ Planificación y seguimiento de tareas del proyecto

◾ Seguimiento de recursos y tiempo
◾ Seguimiento de horas laborales
◾ Captura de tiempo y facturación
◾ Informe de tiempo
◾ Presupuesto de proyectos
◾ Comunicación del proyecto
◾ Documentación del proyecto
Las herramientas de gestión de proyectos para toda la empresa permiten realizar un seguimiento de las personas que trabajan
y ayuda en la identificación de dependencias y problemas entre proyectos. También integran tareas, recursos,
y costos en un solo repositorio. Si la dirección ha decidido utilizar herramientas de medición y tiempo,
como el método de ruta crítica (CPM), la técnica de revisión de evaluación del programa (PERT) o Gantt
gráficos, el auditor, por ejemplo, debe asegurarse de que estas herramientas se utilizan de acuerdo con las
especificaciones de la gerencia. El uso de una de estas herramientas puede ayudar a la gerencia o al auditor
con gestión del tiempo para todo el proyecto. El auditor también puede utilizar estas herramientas para ayudar a obtener
recomendaciones y mostrarle a la gerencia cuánto tiempo se necesita para implementar las recomendaciones.
controles reparados.
Página 217
Las herramientas de gestión de proyectos adicionales son hojas de tareas, que se utilizan para asignar tiempo (real
versus pronosticado), asigne personal y registre la fecha de finalización y el costo. De esta forma, el auditor
y la dirección puede obtener una descripción más detallada del tiempo y el dinero gastados en un proyecto
y puede rastrear en qué se está trabajando y qué se terminó. Los proyectos futuros se benefician más de
estas hojas de tareas porque la gerencia puede basar las estimaciones de proyectos futuros en un historial de tiempos y
costos.
La complejidad de los proyectos actuales prácticamente requiere el uso de herramientas como Microsoft Project
y Open Plan de Deltek. Por ejemplo, Microsoft Project proporciona una herramienta flexible diseñada para ayudar
los gerentes de proyecto manejan una amplia gama de proyectos. El director del proyecto puede programar y de cerca
realizar un seguimiento de todas las tareas, así como utilizar Microsoft Project Central, el complemento web de Microsoft
Proyecto, para intercambiar información del proyecto con el equipo del proyecto y la alta dirección. Algunos de
los principales beneficios y características de Microsoft Project incluyen:
◾ Diagrama de Gantt personal. Representa vistas de Gantt como las de Microsoft Project para delinear cada
propias tareas de los miembros del equipo en varios proyectos.
◾ Delegación de tareas.del
líderes a miembros Una vez asignadas
equipo o de igualpor el director
a igual. del proyecto,
La función las tareas
de delegación se pueden
también delegar
se puede del equipo
desactivar
Si es deseado.
◾ Ver el tiempo no laborable. Los miembros del equipo pueden informar el tiempo no laborable al director del proyecto,
como vacaciones o licencia por enfermedad, y también informar el tiempo de trabajo que no se puede dedicar al
proyecto.
◾ Rendimiento de la base de datos. Obtiene un mejor rendimiento y acceso a los datos con cambios en el
Base de datos de Microsoft Project.
◾ Diagrama de red. Personaliza los diagramas de red con nuevas opciones de filtrado y diseño.
funciones de formato mejoradas y estilos de caja mejorados.
Otra herramienta de gestión de proyectos es el Open Plan de Deltek, que permite al director del proyecto
monitorear y evaluar de cerca las prioridades, los riesgos y el estado de un proyecto desde su inicio hasta su finalización. *
Open Plan es un sistema de gestión de proyectos empresariales que mejora sustancialmente una organización.
la capacidad de realizar múltiples proyectos a tiempo y dentro del presupuesto. Con análisis multiproyecto,
planificación de rutas críticas y gestión de recursos, Open Plan ofrece el poder y la flexibilidad para
atender las diferentes necesidades de las empresas, los recursos y los directores de proyectos.
Certificación de gestión de proyectos

La Certificación PMP, una certificación reconocida mundialmente ofrecida por el PMI, valida el proyecto
ect el conocimiento, la experiencia y las habilidades del gerente para llevar proyectos a una finalización exitosa. †
La certificación reconoce la experiencia y las capacidades del gerente de proyecto para liderar y
Gestión de proyectos. A medida que sigue aumentando la demanda de directores de proyectos cualificados,
Los profesionales de los directores de proyectos no solo se convertirán en una necesidad, sino que estarán en una mejor posi
obtener salarios más altos que los gerentes no certificados.
* https://www.deltek.com/en/products/project-and-portfolio-management/open-plan/benefits-by-role/
gestión de proyectos.
† http://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/project-management-professional-
handbook.pdf.
Página 218
La Certificación PMP evalúa a los candidatos en cinco grupos de procesos PMBOK esenciales que superan
alinear las habilidades y competencias necesarias para que los gerentes lideren proyectos hacia soluciones exitosas. Estas
cinco áreas de gestión de proyectos o grupos de procesos incluyen * :
1. Inicio: involucra los procesos, actividades y habilidades necesarias para definir de manera efectiva el inicio
de un proyecto. Estos involucrarían el establecimiento de permisos, autorizaciones, órdenes de trabajo iniciales y
fases claras para completar el trabajo, así como la inicialización de equipos y la aprobación
presupuesto antes de que comience el proyecto.
2. Planificación: grupo de procesos que define el alcance del proyecto; establece planes estratégicos para maximizar
mize el flujo de trabajo; identifica las metas y expectativas del proyecto; reúne listas de prioridades y planifica
necesidades del equipo; y delinea la infraestructura del proyecto necesaria para lograr los objetivos deseados
basado en cronogramas y limitaciones presupuestarias.
3. Ejecución: grupo de procesos con actividades que involucran la gestión de equipos de manera efectiva (es decir,
abordar las preocupaciones del equipo u otras situaciones complejas) mientras se coordinan las expectativas y
alcanzar los objetivos de referencia a tiempo y dentro del presupuesto.
4. Supervisión y control: implica el procesamiento de las órdenes de cambio, abordando el presupuesto continuo.
consideraciones, y mitigar circunstancias imprevistas que puedan afectar la capacidad de un equipo para
cumplir con las metas y expectativas iniciales del proyecto.
5. Cierre: este grupo de proceso se relaciona con la entrega de un proyecto a un cierre exitoso (es decir, a tiempo
y dentro del presupuesto). Un buen cierre trae excelentes críticas y puede aumentar las noticias futuras
referencias de boca.
Cada grupo de procesos anterior contiene el conocimiento y las habilidades necesarias para desempeñarse de manera eficaz
Tareas de gestión de proyectos de carpa, incluida la provisión de las habilidades profesionales necesarias para liderar equipo
y lograr resultados de proyectos exitosos.
Gestión de programas
La gestión de programas es el proceso necesario para coordinar múltiples proyectos relacionados con el
propósito de brindar beneficios comerciales de importancia estratégica. Aplicaciones complejas de hoy
(es decir, los sistemas de planificación de recursos empresariales) integran los requisitos y la funcionalidad de múltiples
múltiples grupos y múltiples aplicaciones. La mayoría de las aplicaciones nuevas también requieren la acción de varios
funciones dentro de TI (por ejemplo, desarrollo de software, ingeniería de redes, seguridad, producción
soporte, etc.). La gestión de programas reúne todas las piezas de un programa principal. Lo hace
Entonces por:
◾ Definición de un marco de gestión de programas

◾ Creación de una oficina de gestión de programas
◾ Establecer requisitos de personal, procesos y métricas
◾ Establecer prácticas de gestión de proyectos coherentes
◾ Implementación de tecnología para la gestión de proyectos
* http://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/project-managementprofessional-exam-
esquema.pdf.
Página 219
Según una investigación realizada por Gartner Group, las organizaciones que establecen empresas
estándares para la gestión de programas y proyectos, incluida una PMO con una gobernanza adecuada,
Experimentar la mitad de los sobrecostos, retrasos y cancelaciones de los proyectos que no
hazlo.
Gestión de proyectos: función del auditor

El papel del auditor en la gestión de proyectos depende de la cultura de la organización, la madurez del
función de los sistemas de información y filosofía del departamento de auditoría. El objetivo de un
La auditoría de gestión de proyectos es para proporcionar una identificación temprana de los problemas que pueden obstacul
implementación completa de una aplicación que está controlada, documentada y puede ser operada por
una comunidad de usuarios capacitados. La auditoría de la gestión de proyectos requiere conocimientos específicos sobre
metodología del proyecto y proceso de desarrollo. Comprenderlos permite al auditor identificar
áreas clave que se beneficiarían de una verificación independiente.
El alcance de una auditoría de gestión de proyectos puede incluir una evaluación de los
controles sobre el proyecto (por ejemplo, resultados de viabilidad, dotación de personal, presupuestación, asignación de
vínculos, planes de proyecto, informes de estado, etc.) o una evaluación de entregables específicos para validar que el
El proyecto sigue los estándares establecidos. Al involucrarse en puntos estratégicos, el auditor
puede garantizar un proyecto bien controlado. Si el auditor siente que sus conocimientos, habilidades y
habilidades no están al día con las tecnologías que se están aplicando, debe solicitar
capacitación en la tecnología antes de ser asignado. Asistir a sesiones de capacitación concurrentes con
el auditado puede ayudar a comprender las herramientas y técnicas disponibles para él. El seguimiento-
La lista de resultados destaca algunas de las tareas clave que el auditor puede realizar durante el desarrollo de un proyecto:
◾ Obtenga el apoyo y la cooperación de los usuarios y profesionales de TI

◾ Verifique las herramientas de gestión de proyectos para su uso adecuado
◾ Realizar revisiones del proyecto al final de cada fase
◾ Evaluar la preparación para la implementación
◾ Presentar los hallazgos a la gerencia
◾ Mantener la independencia para seguir siendo objetivo
Para determinar el nivel de participación, el auditor primero debe completar una evaluación de riesgo del
proceso de desarrollo del proyecto y determinar la cantidad de tiempo que se asignará a un
proyecto. A continuación, el auditor debe desarrollar un plan de auditoría que incluya un cronograma para el
puntos de revisión vinculados al cronograma del proyecto. El auditor luego comunica el alcance de su
participación, así como cualquier hallazgo para el gerente del proyecto, los usuarios y la administración de TI.
Dependiendo de la organización, los auditores pueden no tener suficiente tiempo para participar en todas las fases.
de cada proyecto. La participación del proyecto dependerá de la evaluación de los riesgos del proceso y del proyecto.
Los riesgos del proceso pueden incluir un clima organizacional negativo, así como la falta de dirección estratégica.
ción, estándares de gestión de proyectos y proceso formal de gestión de proyectos. Riesgos del proyecto, en el
Por otro lado, implican falta de disponibilidad de recursos, sobrecostos presupuestarios, complejidad y magnitud del proyect
personal sin experiencia y falta de participación del usuario final y compromiso de la administración; entre
otros.
Página 220
El nivel de riesgo puede ser una función del tamaño del proyecto, el alcance del cambio organizacional,
la complejidad del sistema de aplicación que se está desarrollando, el número de personas involucradas y el
importancia del proyecto para la organización. El alcance de la participación de la auditoría dependerá de
la madurez de la gestión de proyectos en la organización. La participación de la auditoría puede ser mínima si
el grupo de TI tiene una metodología de proyecto bien establecida y una PMO que realiza O&T regularmente
ocupaciones. En este caso, el auditor puede centrarse más en los riesgos específicos del proyecto que en el proyecto.
riesgos de gestión. Para organizaciones menos maduras, los auditores también pueden asumir el papel de supervisar
el proyecto y seguimiento de sus tareas y actividades.
Plan de auditoria
El plan de auditoría detallará los objetivos y los pasos para cumplir con los objetivos de la auditoría. Como en cualquier
auditoría, una auditoría de gestión del proyecto comenzará con un análisis preliminar del entorno de control
revisando los estándares y procedimientos existentes. Durante la auditoría, estas normas y
los procedimientos deben evaluarse para verificar su integridad y eficiencia operativa. La encuesta preliminar
debe identificar la estrategia de la organización y las responsabilidades de gestión y control
desarrollo.
El plan de auditoría incluiría una revisión del proceso de gestión del proyecto para evaluar la idoneidad
del entorno de control para la gestión de proyectos. Los puntos de revisión enumerados representan puntos de control
en el proceso de gestión de proyectos. Los auditores pueden utilizar estos puntos de control para determinar tanto el estado
tus del sistema de control interno del proyecto y el estado del proyecto de desarrollo en sí. Estas
las revisiones eliminan la necesidad de dedicar grandes cantidades de recursos de auditoría al desarrollo
esfuerzo. Siempre que el proceso de desarrollo esté bien controlado, la necesidad de participación de la auditoría es
minimizado.
El plan de auditoría ayudará aún más al director del proyecto a identificar los riesgos del proyecto y evaluar
la elaboración de planes para mitigar y gestionar esos riesgos, como contar con recursos capacitados y dedicados,
apoyo a la gestión y compromiso del usuario final. La auditoría puede proporcionar a la administración una
revisión independiente de los entregables del proyecto, como el estatuto del proyecto, la lista de tareas, el cronograma y el p
La auditoría también puede revisar la lista de tareas del proyecto y el presupuesto para verificar que todas las tareas del proy
definido y todos los hitos tienen un entregable.
Durante la fase de planificación, el auditor puede facilitar la comunicación entre funciones y
plantear cuestiones que puedan afectar la calidad o la puntualidad del proyecto. En un desarrollo de software
proyecto, por ejemplo, los recursos de varios departamentos deben unirse para implementar un
proceso automatizado que puede afectar las funciones de múltiples usuarios. Debido a varios proyectos de auditoría,
Los docentes desarrollan un conocimiento general de la organización y establecen relaciones con múltiples
grupos y departamentos, incluidos:
◾ Usuarios principales
◾ Usuarios secundarios
◾ Proveedores y consultores
◾ Programadores y analistas
◾ Administradores de bases de datos
◾ Equipos de prueba
◾ Operaciones informáticas
◾ Sistemas de interfaz
◾ Equipo de implementación
◾ Programadores de soporte y mantenimiento de producción
Página 221
Estas relaciones son útiles en un proyecto de desarrollo de software para asegurarse de que la información
fluye entre el equipo de desarrollo y otros funcionarios.
Comunicación del alcance de la participación y recomendaciones

La primera área a comunicar es el rol de participación del auditor en la auditoría de gestión del proyecto. Eso
Es muy importante asegurarse de que se comprendan y comprendan las expectativas del papel del auditor.
comunicada a todos los participantes. El auditor debe desarrollar una línea abierta de comunicación con ambos
gestión y usuarios. Si no existe una buena relación entre estos grupos, la información
podría ser retenido del auditor. Este tipo de situación podría impedir que el auditor
el mejor trabajo posible. Además, el auditor debe desarrollar una buena relación de trabajo con el
gerente, analistas y programadores. Aunque el auditor debe cultivar un buen trabajo
relaciones con todos los grupos que tienen responsabilidades de diseño, él o ella deben permanecer independientes.
Durante el desarrollo de un proyecto, el auditor hará recomendaciones de control
ciones. Dependiendo de la cultura de la organización, estas recomendaciones pueden necesitar ser manejadas
informalmente revisando los diseños con el equipo del proyecto o formalmente presentando recomendaciones
al comité directivo. En cualquier caso, el auditor siempre debe considerar el valor del contrato.
recomendación de control versus el costo de implementar dicha recomendación. Recomendaciones
debe ser específico. Deben identificar el problema, no el síntoma, y permitir la adecuada
controles para ser implementados y probados.
Las recomendaciones a menudo se rechazan debido a un factor de tiempo y costo. Los gerentes de proyecto pueden
a veces siente que implementar las recomendaciones de un auditor las retrasará.
El auditor debe convencer a la gerencia del valor de las recomendaciones, y que si son
Si no se implementa, se gastará más tiempo y dinero a largo plazo. Informar a la dirección de
el costo de implementar una recomendación de control ahora en lugar de apagar el sistema
más tarde repararlo o dejar abiertas las posibles exposiciones ayudará a convencer a la dirección de la necesidad de
invierta el tiempo y el dinero necesarios.
Gestión de proyectos de Big Data

Los macrodatos ofrecen importantes ventajas y desafíos para los profesionales del campo de la gestión de proyectos.
Big data, según la definición de la Comisión Federal de Big Data de la TechAmerica Foundation (2012),
“Describe grandes volúmenes de datos de alta velocidad, complejos y variables que requieren tecnología avanzada
niques y tecnologías para permitir la captura, almacenamiento, distribución, gestión y análisis de
la información." Gartner, Inc. lo define además como "... alto volumen, alta velocidad y / o alta
una variedad de activos de información que exigen formas innovadoras y rentables de procesamiento de información
que permiten una mejor comprensión, toma de decisiones y automatización de procesos ".
Aunque los macrodatos precisos pueden conducir a un proceso de toma de decisiones más seguro y mejor
decisiones a menudo resultan en una mayor eficiencia operativa, reducción de costos y reducción del riesgo, muchas
Actualmente existen desafíos que deben abordarse. Los desafíos de big data incluyen, por ejemplo, análisis
análisis, captura, conservación de datos, búsqueda, uso compartido, almacenamiento, transferencia, visualización, consulta, a
actualización. Ernst & Young, en su publicación de septiembre de 2015 del EY Center for Board Matters, afirma
que los desafíos para los auditores incluyen el acceso limitado a los datos relevantes de auditoría; escasez de disponibilidad y
personal calificado para procesar y analizar estos datos particulares; y la integración oportuna de análisis
ics en la auditoría. Estos desafíos de big data también han afectado al campo de la gestión de proyectos. Cuanto mas
Hay más datos que se necesitan analizar y más proyectos se deben gestionar.
Página 222
El análisis de cantidades significativas de datos es crucial para identificar patrones y tendencias, así como para
crear procesos y soluciones eficientes y eficaces. Los gerentes de proyecto deben embarcarse en esta relación
un viaje de big data completamente nuevo para tomar decisiones corporativas efectivas. Los análisis de big data permiten
gerentes de proyecto para identificar qué procesos, soluciones o tecnologías brindan el mejor rendimiento o
ventaja competitiva para la organización. A medida que los datos continúen adquiriendo más valor intrínseco,
convertirse en un punto estratégico y focal para las empresas. La figura 7.4 sugiere algunas de las habilidades esenciales
necesario para que los directores de proyectos gestionen con éxito un proyecto de big data.
Figura 7.4 Habilidades esenciales de Big Data para directores de proyectos
Habilidad Descripción
Multifuncional Los gerentes de proyecto deben expandir su equipo y conjuntos de habilidades para incluir un
equipo diverso grupo de profesionales, incluidas las disciplinas de la ingeniería,
administración científicos, analistas de negocios, "super" usuarios de negocios, operaciones, etc.
experiencia
Habilidad de ver el La capacidad de ver el panorama general al administrar un proyecto de big data es
cuadro grande crítico para los gerentes de proyecto para "dar sentido" a todos los diversos y
datos complejos.
Basado en datos Los gerentes de proyecto deben emplear el pensamiento basado en datos en lugar de confiar
pensando en experiencias pasadas o instintos. El enfoque para gestionar un big data
el proyecto debe estar impulsado por el descubrimiento donde se toman decisiones
basado en datos y análisis y no en la intuición y experiencia de
el director del proyecto. Esto será clave para realizar plenamente el potencial
valor de los datos.
Habilidad para lidiar En los proyectos de big data, los gerentes deben aceptar (y sentirse cómodos
con ambigüedad con) lo desconocido, ya que no siempre tendrán las respuestas correctas.
Los gerentes de proyecto deben comprometerse a descubrir soluciones a los problemas a través de
experimentación y hallazgos basados en evidencia.
Habilidades técnicas Los gerentes de proyecto deben mejorar las habilidades técnicas existentes para abordar grandes
tareas y desafíos de datos.
Proceso Para adaptar los procesos existentes de una organización a big data, procese
desarrollo habilidades de desarrollo, como utilizar los recursos de manera eficiente (es decir, tiempo,
habilidades dinero, materias primas y trabajo); mejorar la calidad de los productos,
servicios y datos; y atender las necesidades de los mercados se convierten en
necesario para los jefes de proyecto.
Habilidades blandas Deben adquirirse nuevas habilidades blandas, o pulirse las habilidades blandas existentes, para
incluir colaboración, curiosidad y creatividad, que son vitales
cualidades para entregar proyectos exitosos de big data.
Buen negocio Se requerirá que los gerentes de proyecto cambien del proyecto tradicional
juicio gestión (por ejemplo, planificación, identificación, mitigación de riesgos, etc.) para
centrándose en ofrecer una tecnología rápida, eficaz y definida
solución para problemas empresariales.
Página 223
Conclusión
La gestión de proyectos es uno de los controles clave que garantiza la entrega de los proyectos a tiempo, dentro del presupue
y con plena funcionalidad. El propósito de la gestión de proyectos es identificar, establecer, coordinar
identificar y monitorear actividades, tareas y recursos para un proyecto que sea consistente con los objetivos y
objetivos de la organización. El control eficaz de los proyectos requiere un enfoque disciplinado para
sus diversos ciclos de vida: inicio de proyectos; planificación; ejecución; monitoreando y controlando; y
clausura. Estos cinco ciclos, dominios o grupos de procesos contienen tareas, que incluyen conocimientos y
habilidades, se relacionan con la participación de las personas adecuadas, siguiendo los pro-
ceses y el uso de un conjunto de herramientas de gestión de proyectos para una ejecución eficaz.
La principal organización de estándares para la gestión de proyectos es el PMI, que ofrece valor
a los profesionales a través de la promoción, la colaboración, la educación y la investigación globales. El Instituto
Los estándares reconocidos mundialmente han sido clave en el desarrollo y madurez de la gestión del proyecto.
profesión de envejecimiento. El PMBOK del PMI incluye conocimiento de prácticas innovadoras y avanzadas
dentro
y GAPPSde la
sonprofesión de gestión
bien conocidos y sedehan
proyectos. Otras
establecido autoridades
para avanzar enlíderes comodelaproyectos
la gestión AIPM, la IPMA,
profesión. Los gerentes de proyecto emplean metodologías (mejores prácticas, técnicas o procedimientos) para
el diseño, planificación, implementación y logro de los objetivos del proyecto. Hay diferentes
metodologías de gestión de proyectos en beneficio de diferentes proyectos y organizaciones.
Establecer y cumplir una metodología de gestión de proyectos proporcionará una adecuada
entorno para el proyecto, pero no garantizará su éxito. La gestión de proyectos tiene la
igualar la responsabilidad por el éxito o fracaso de cualquier proyecto a través de una planificación adecuada, recursos
gestión, O&T y el empleo eficaz de herramientas de gestión. Obtener la certificación como
PMP también ha demostrado ser útil para llevar proyectos a un final exitoso.
La gestión de programas es un control útil que se utiliza para coordinar varios proyectos relacionados con
el propósito de brindar beneficios comerciales de importancia estratégica. También ofrece muchas oportunidades
entidades para auditores. Los auditores deben desarrollar las habilidades y relaciones necesarias para trabajar con
el equipo del proyecto para asegurarse de que los controles se consideren y se incorporen al sistema de manera adecuada.
Los auditores pueden ayudar a las organizaciones revisando el entorno de gestión de proyectos, incluyendo
herramientas, evaluación de estándares para la gestión de proyectos, seguimiento del progreso del proyecto y evaluación
fases en el proyecto global, entre otras.
Los gerentes de proyecto deben adquirir nuevas habilidades o pulir las existentes al administrar big data
proyectos. La gestión exitosa de proyectos de big data permite a los gerentes de proyecto hacer corporativos
decisiones, así como identificar los procesos, soluciones o tecnologías que brindan el mejor retorno
o ventaja competitiva para la organización. A medida que los datos continúan adquiriendo más valor intrínseco,
se convertirá en un punto estratégico y focal para las empresas.
1. Explique a qué se refiere la gestión de proyectos.
2. Enumere 10 controles que normalmente se consideran en la gestión de proyectos, según COBIT.
3. Explique por qué / cómo la gestión de proyectos a menudo se ha descrito como parte arte y parte ciencia.
4. ¿Cuál es la organización de estándares principal para la gestión de proyectos y cuál es su propósito?
5. ¿Qué se incluye en el Cuerpo de Conocimientos de Gestión de Proyectos (PMBOK)?
6. Diferenciar entre las metodologías de gestión de proyectos tradicionales y ágiles.
7. Enumere y explique brevemente los factores clave de éxito para una gestión eficaz del proyecto.
Página 224
8. ¿Cuál es la diferencia entre la gestión de programas y proyectos? ¿Cómo maneja el programa

¿La gestión reúne todas las piezas del programa?
9. Enumere las tareas clave que el auditor puede realizar durante el desarrollo de un proyecto.
10. Describir los desafíos actuales de big data para las organizaciones. ¿Cómo impactan estos desafíos
directores de proyectos y el campo de la gestión de proyectos?
Ejercicios
1. Enumere y describa siete mejores prácticas para una oficina de gestión de proyectos (PMO) eficaz,
según el Grupo Gartner.
2. Metodología de Gestión de Proyectos (“Metodología”) - Asignación y Presentación de Grupos.
El profesor dividirá la clase en grupos y asignará las Metodologías del Anexo 7.1. Grupos
saldrá del libro de texto (es decir, literatura de TI y / o cualquier otra fuente externa válida) para
resumir y presentar a la clase las Metodologías asignadas. La presentación debe:
a. Proporcione una explicación general de la Metodología, que incluya, entre otros: definición
ción; Proposito y objetivos; ya sea en los Estados Unidos o en el extranjero; indus-
intentos en los que se han utilizado metodologías; etc.
segundo. Resalte los beneficios y desafíos de la Metodología a los gerentes de proyectos.
C. Incluya ejemplos de organizaciones que han utilizado la Metodología particular y, si
disponibles, describa su experiencia general.
re. Presentarse en formato de presentación de power-point con una portada y una sección de referencia.
ción al final. El archivo enviado debe tener entre 8 y 10 páginas, incluyendo
portada y referencias.
3. Resuma los pasos que los auditores deben seguir para determinar su nivel de participación en
una auditoría de gestión de proyectos.
4. El Cuadro 7.4 enumera las habilidades esenciales para los gerentes de proyectos de big data. Piense en (y enumere) tre
cinco habilidades adicionales que ayudarían a los gerentes de proyecto cuando se trata de proyectos de big data.
Explique el fundamento de cada habilidad agregada.
CASO: FALLAS DE GESTIÓN DE PROYECTOS DE TI
INSTRUCCIONES: Según un estudio de 2012 realizado por la firma McKinsey & Co. y
la Universidad de Oxford, “En promedio, los grandes proyectos de TI superan en un 45% el presupuesto y un 7%
tiempo, al tiempo que ofrece un 56% menos de valor de lo previsto ". El estudio de McKinsey se centró en proyectos
de $ 15 millones o más.
TAREA: Con un navegador web de Internet, busque y examine tres recientes (dentro de los últimos 5
años) proyectos de TI que han fracasado. Resuma por qué fallaron. Luego, identifique soluciones o
cómo se pudieron haber evitado estos fallos. Apoye sus razones con literatura de TI y / o
cualquier otra fuente externa válida. Incluya ejemplos según corresponda para evidenciar su caso.
Envíe un archivo de Word con una portada, respuestas a las tareas anteriores y una sección de referencia.
al final. El archivo enviado debe tener entre 8 y 10 páginas (interlineado doble),
incluyendo portada y referencias. Esté preparado para presentar su trabajo a la clase.
Página 225
Otras lecturas
1. Instituto Australiano de Gestión de Proyectos (AIPM). www.aipm.com.au/about-us (consultado el 20 de junio de
2017).
2. Best, K., Zlockie, J. y Winston, R. (2011). Estándares internacionales para la gestión de proyectos. Papel
presentado en el Congreso Global de PMI® 2011 — Norteamérica, Dallas, TX. Newtown Square, PA:
Instituto de manejo proyectos.
3. Bloch, M., Blumberg, S. y Laartz, J. (2012). Entrega de proyectos de TI a gran escala a tiempo, dentro del presupuesto,
y en valor. McKinsey & Company - Digital McKinsey, www.mckinsey.com/business-functions/
digital-mckinsey / our-insights / entregando-proyectos-de-it-a-gran-escala-a tiempo-según-presupuesto-y-valor
(consultado el 6 de febrero de 2017).
5. Crawford, T. (2013). Gestión de proyectos de Big Data Analytics . Publicación independiente de CreateSpace
Plataforma, Portsmouth, NH.
6. Doerscher, T. (2008). Informe de la encuesta PMO 2.0 . La continua evolución del proyecto, programa y
Oficina de gestión de carteras (PMO) , Planview, Inc., 2009.
7. EY. Big data y analítica en el proceso de auditoría. EY Center for Board Matters, septiembre de 2015. www.
ey.com/Publication/vwLUAssets/ey-big-data-and-analytics-in-the-audit-process/$FILE/ey-big-data-
and-analytics-in-the-audit-process.pdf
8. Flynn, TA (2007). Integración del ciclo de vida de la gestión de proyectos (PMLC) y el desarrollo de sistemas
ciclo de vida de los elementos (SDLC) en esfuerzos de proyectos acelerados: adaptación de las mejores prácticas de gestión de p
a solicitudes irrazonables. Documento presentado en el PMI® Global Congress 2007 — Norteamérica, Atlanta,
GEORGIA. Newtown Square, PA: Instituto de Gestión de Proyectos.
9. Fuster, JE (2006). Comparación de la gestión del ciclo de proyectos de la Comisión Europea / lógica
enfoque marco con estándares y metodologías internacionales de PM: PMBOK, ICB de IPMA,
ISO 10,006, PRINCE2 y TenStep. Documento presentado en PMI® Global Congress 2006 — EMEA,
Madrid, España. Newtown Square, PA: Instituto de Gestión de Proyectos.
10. La Alianza Global para Estándares de Desempeño de Proyectos (GAPPS). http://globalpmstandards.org/
about-us / (consultado el 20 de junio de 2017).
11. Gartner identifica siete mejores prácticas para una oficina de gestión de proyectos eficaz. Abril de 2016. Prensa
Lanzamiento. Stamford, CT. www.gartner.com/newsroom/id/3294017
12. Glosario de TI de Gartner. (nd) www.gartner.com/it-glossary/big-data/
13. Gilchrist, P. (2014). Habilidades de gestión de proyectos para la gestión de proyectos de big data. El proyecto
Guía del administrador de Big Data . www.freepmstudy.com/BigData/BigDataPMSkills.cshtml (consultado
17 de junio de 2017).
14. Gomolski, B. y Smith, M. Gestión de programas y carteras: cómo llegar al siguiente nivel , Gartner
Research, G00155601, Gartner Group, Stamford, CT, 27 de noviembre de 2006.
15. Descripción general del método HERMES. www.hermes.admin.ch/onlinepublikation/index.xhtml (consultado en junio
15, 2017).
16. Grupo MC2. (2016). Impacto del big data en la gestión de proyectos. www.mc2i.fr/Impact-of-Big-Data-
in-Project-Management (consultado el 24 de junio de 2017).
17. Asociación Internacional de Gestión de Proyectos (IPMA). www.ipma.world/about/ (consultado el 20 de junio de
2017).
18. Guía de ISO 10006: 2003 - Sistemas de gestión de la calidad y directrices para la gestión de la calidad
en Proyectos. www.iso.org/standard/36643.html (consultado el 3 de junio de 2017).
19. Katcherovski, V. (2012). 5 metodologías efectivas de gestión de proyectos y cuándo utilizarlas. Lógica
Software, Inc. https://explore.easyprojects.net/blog/project-management-methodologies
20. Project Management Institute (PMI). Obtenga más información sobre PMI. www.pmi.org/about/learn-about-pmi
21. Light, M. y Halpern, M. Comprender la gestión de la cartera de productos frente a la de proyectos , Gartner Research,
G00130796, Gartner Group, Stamford, CT, 2 de mayo de 2006.
Página 226
22. Instituto de Gestión de Proyectos. Metodología. www.pmi.org/learning/featured-topics/methodology

23. Mullaly, M. (2013). Big Data y gestión de proyectos: ¿tiene sentido? Gestión de proyectos.Com.
www.projectmanagement.com/articles/281365/Big-Data---Project-Management--Is-There-a-Point-
24. Project Management Institute (PMI). Guía y estándares del PMBOK® . www.pmi.org/pmbok-guide-
estándares (consultado el 17 de junio de 2017).
25. KPMG, LLP. Gestión de carteras, programas y proyectos. https://advisory.kpmg.us/management-
consulting / capacity / portfolio-program-and-project-management.html (consultado el 2 de junio de 2017).
26. TutorialsPoint. Metodologías de gestión de proyectos. https://www.tutorialspoint.com/management_
concept / project_management_methodologies.htm (consultado el 14 de junio de 2017).
27. Project Management Institute, Inc. (2017). Esquema del examen profesional de gestión de proyectos. www.
pmi.org/-/media/pmi/documents/public/pdf/certifications/project-management-professional-exam-
esquema.pdf
28. Project Management Institute, Inc. (2017). Manual profesional de gestión de proyectos. www.pmi.
org / - / media / pmi / documents / public / pdf / certifications / project-management-professional-handbook.
pdf
29. Scheid, J. (2015). Metodologías de gestión de proyectos: ¿cómo se comparan? Bright Hub Inc.
www.brighthubpm.com/methods-strategies/67087-project-management-methodologies-how-do-
ellos comparan /
Taylor y Francis: Boca Raton.
31. Singleton, T. (2006). Lo que todo auditor de TI debe saber sobre la gestión de riesgos de proyectos. ISACA. , 5,
17-20.
32. Smith, M. Exprese el valor del proyecto de TI en términos comerciales utilizando el valor total de oportunidad de Gartner
Metodología , Gartner Research, G00131216, Gartner Group, Stamford, CT, 11 de enero de 2006.
33. Comisión Federal de Big Data de la Fundación TechAmerica. Desmitificando Big Data: una guía práctica
a transformar el negocio del gobierno. (2012). www.techamerica.org/Docs/fileManager.
cfm? f = techamerica-bigdatareport-final.pdf
34. AACE International. Marco de gestión de costes totales (TCM). http://web.aacei.org/resources/pub-
licaciones / tcm (consultado el 14 de junio de 2017).
35. ILX Group 2017. ¿Qué es PRINCE2? www.prince2.com/usa/what-is-prince2 (consultado el 15 de junio de
2017).
Página 227
Capítulo 8
Desarrollo del sistema

Ciclo vital
1. Analice el ciclo de vida del desarrollo del sistema (SDLC) y sus fases comunes.
2. Discuta los riesgos adicionales y los controles asociados relacionados con las fases de SDLC.
3. Explique los enfoques comunes utilizados para el desarrollo de software.
4. Analice la participación del auditor de TI en el proceso de desarrollo e implementación del sistema.
Las organizaciones están constantemente construyendo, reemplazando y manteniendo sistemas de información. Existen
muchos enfoques diferentes para el desarrollo de sistemas, pero los sistemas más exitosos siguen un buen
metodología de desarrollo definida. El éxito de un proyecto de desarrollo de sistemas depende
sobre el éxito de los procesos clave: gestión de proyectos, análisis, diseño, pruebas e implementación
ción. Debido a que los esfuerzos de desarrollo pueden ser costosos, las organizaciones han reconocido la necesidad de constr
sistemas de calidad bien controlados. TI procesa información que es integral para la estabilidad financiera
y rentabilidad de las organizaciones. Por tanto, estos sistemas deben construirse con una adecuada
controles para garantizar la integridad y precisión del procesamiento de transacciones.
Ciclo de vida de desarrollo de sistemas

Como se discutió en el capítulo anterior, el ciclo de vida de la gestión de un proyecto proporciona pautas para el proyecto.
gerentes sobre los procesos que deben seguirse para asegurar el éxito general de un proyecto. en un
De manera similar, el ciclo de vida de desarrollo del sistema (SDLC), también conocido como el
ciclo de vida de desarrollo de la aplicación, proporciona un marco para el desarrollo eficaz de sistemas de aplicación.
Describe específicamente un proceso estándar para planificar, crear, probar e implementar nuevos
sistemas de información (es decir, nuevo desarrollo o sistema modificado). O desarrollando un nuevo sistema
o agregar cambios a uno existente, el SDLC proporciona el marco y los pasos necesarios para
una implementación adecuada. Aunque existen muchas variaciones del SDLC tradicional,
todos tienen las siguientes fases comunes de una forma u otra (consulte el Anexo 8.1):
201
Página 228
1. Planificación
7. Operaciones y
2. Sistema
mantenimiento
análisis y
requisitos
6. Implementación 3. Diseño del sistema
5. Prueba 4. Desarrollo
Figura 8.1 Fases del ciclo de vida del desarrollo del sistema.
1. Planificación
2. Análisis y requisitos del sistema
3. Diseño del sistema
4. Desarrollo
5. Prueba
6. Implementación
7. Operaciones y mantenimiento
Planificación
La fase de planificación prepara el escenario para el éxito del esfuerzo de desarrollo del sistema. Documenta
las razones para desarrollar el nuevo sistema (en lugar de comprarlo de una fuente externa) en
para lograr las metas y objetivos estratégicos de la organización. Durante la planificación, las organizaciones
establecer el alcance del trabajo (considerando costos, tiempo, beneficios y otros elementos), establecer iniciativas
adquirir los recursos necesarios y determinar soluciones. Si la planificación no se realiza correctamente,
El presupuesto y el cronograma pueden no ser suficientes, el problema comercial o debe ser abordado por el
el nuevo sistema puede no estar adecuadamente definido, el producto final puede no resolver el problema o la necesidad,
y las personas adecuadas pueden no estar involucradas. Estos son los riesgos típicos que enfrentan los auditores de TI y
personal de la organización durante esta fase. Para ser eficaz, la planificación debe incluir y describir
el seguimiento:
◾ Necesidad de un nuevo análisis del sistema. Un estudio para determinar si un nuevo sistema debe ser
desarrollado internamente o comprado de fuentes externas.
◾ Revisión del sistema actual. Un estudio del sistema actual para identificar los procesos existentes y
procedimientos que continuarán en el nuevo sistema.
◾ Diseño conceptual. Elaboración y evaluación de las alternativas de diseño propuestas, sistema
flujos y otra información que ilustre cómo funcionará el nuevo sistema.
◾ Requisitos de equipo. Identificación de la configuración de hardware necesaria para utilizar el nuevo
sistema (por ejemplo, velocidad de procesamiento, espacio de almacenamiento, medios de transmisión, etc.).
◾ Análisis de costo / beneficio. Análisis financiero detallado del costo de desarrollar y operar el nuevo
sistema, los ahorros o gastos adicionales y el retorno de la inversión.
Página 229
Ciclo de vida de desarrollo del sistema ◾ 203
◾ Formación del equipo de proyecto. Identificación y selección de recursos necesarios (por ejemplo, programadores,
usuarios finales, etc.) para desarrollar e implementar el nuevo sistema.
◾ Tareas y entregables. Establecer tareas definidas y entregables para monitorear los resultados reales y
asegurar un progreso exitoso.
Análisis y requisitos del sistema

En esta fase, los analistas de sistemas identifican y evalúan las necesidades de los usuarios finales con el propósito final
de asegurar que, una vez desarrollado, el nuevo sistema cumplirá con sus expectativas. Durante esta fase,
Los usuarios finales y los analistas de sistemas definen los requisitos funcionales para el nuevo software / sistema en
términos que pueden medirse y probarse funcionalmente. La funcionalidad del sistema existente es
coinciden con la nueva funcionalidad y los requisitos se definen y validan con los usuarios para
que pueden convertirse en la base de la fase de diseño del sistema. Esta fase también identifica y documenta
recursos que serán responsables de partes individuales del sistema, así como de la línea de tiempo
esperado. Las herramientas o prácticas comunes utilizadas por las organizaciones durante esta fase incluyen:
◾ Ingeniería de software / sistemas asistidos por computadora (CASE): herramienta de software con métodos para
diseñar, desarrollar e implementar aplicaciones y sistemas de información;
◾ Recopilación de requisitos: práctica de recopilar los requisitos de un sistema de los usuarios,
clientes y otras partes interesadas a través de reuniones o entrevistas; y
◾ Análisis estructurado: técnica de ingeniería de software que utiliza diagramas gráficos para
analizar e interpretar los requisitos y describir los pasos necesarios (y datos) requeridos para
cumplir con la función de diseño del sistema o software en particular.
Diseño de sistemas
En la fase de diseño del sistema, el analista de sistemas define y documenta todas las interfaces del sistema,
informes, diseños de pantalla y lógica de programa específica necesaria para construir el nuevo sistema consistente
con los requisitos. La fase de diseño del sistema describe, en detalle, las especificaciones, características,
y operaciones que cumplan con los requisitos previamente definidos. En esta fase, los analistas de sistemas
y los usuarios finales, una vez más, revisan las necesidades comerciales específicas y determinan (o confirman) qué
serán los requisitos finales para el nuevo sistema. Los detalles técnicos del sistema propuesto son
También se discutió con las diversas partes interesadas, incluido el hardware / software necesario, redes
capacidades, procesamiento y procedimientos para que el sistema logre sus objetivos, etc. Otros
Los temas más generales y administrativos dentro de esta fase incluyen la identificación de riesgos existentes,
tecnologías que se utilizarán, capacidad del equipo, limitaciones del proyecto, plazos y restricciones presupuestarias.
La consideración de lo anterior ayudará a seleccionar el mejor enfoque de diseño.
En la etapa de diseño de sistemas, se deben definir controles para los puntos de entrada y el procesamiento. Pantalla
Los diseños, controles e informes deben ser revisados y aprobados por el usuario final antes de continuar.
a la siguiente fase. Los programadores utilizarán las especificaciones detalladas y la salida del diseño.
fase para pasar a la fase de desarrollo o construcción.
Desarrollo
En la fase de desarrollo, los programadores construyen o construyen el nuevo sistema basándose en análisis,
requisitos y diseño previamente acordado. La fase de construcción o codificación es final una vez que
El programador valida el nuevo código del sistema mediante pruebas unitarias individuales (prueba completa del
Página 230
el sistema se realiza en la siguiente fase). El código se prueba tanto para la sintaxis como para el flujo lógico. Todas
Se ejercen rutas lógicas para garantizar que las rutinas de error funcionen y que el programa finalice el procesamiento.
normalmente.
Cuando se desarrollan nuevos sistemas, es necesario desarrollar controles de acceso de seguridad apropiados
bien para salvaguardar la información contra la divulgación o modificación no aprobada, y el daño o la pérdida.
Los controles de acceso lógico, por ejemplo, se utilizan para garantizar que el acceso a los sistemas, datos y programas
están limitados a los usuarios apropiados y al personal de soporte de TI.
Las organizaciones también deben tener en cuenta que los esfuerzos de desarrollo generan código y que este
es donde comienza la seguridad y el control de cualquier sistema. En marzo de 2011, la computadora de Estados Unidos
El equipo de preparación para emergencias (US-CERT) emitió sus 10 mejores prácticas de codificación segura. Estas practic
debe respetarse al iniciar, diseñar, desarrollar, probar, implementar y mantener un sistema:
1. Valide la entrada. Valide la entrada de todas las fuentes de datos que no sean de confianza. La validación de entrada a
eliminar la gran mayoría de las vulnerabilidades del software. Sospeche de la mayoría de los datos externos
fuentes, incluidos argumentos de línea de comando, interfaces de red, variables ambientales,
y archivos controlados por el usuario.
2. Preste atención a las advertencias del compilador. Compile código utilizando el nivel de advertencia más alto disponi
compilador y elimine las advertencias modificando el código. Utilice análisis estático y dinámico
herramientas para detectar y eliminar fallas de seguridad adicionales.
3. Arquitecto y diseño de políticas de seguridad. Cree una arquitectura de software y diseñe su
software para implementar y hacer cumplir las políticas de seguridad. Por ejemplo, si su sistema requiere
diferentes privilegios en diferentes momentos, considere dividir el sistema en distintos intercomunicadores
subsistemas de comunicación, cada uno con un conjunto de privilegios apropiado.
4. Mantenga el diseño lo más simple y pequeño posible. Los diseños complejos aumentan la probabilidad de que
Se cometerán errores en su implementación, configuración y uso. Además, el esfuerzo
necesario para lograr un nivel apropiado de garantía aumenta drásticamente a medida que la seguridad
los mecanismos se vuelven más complejos.
5. Denegación por defecto. Basar las decisiones de acceso en permisos en lugar de exclusiones. Esto significa que, por
predeterminado, se deniega el acceso y el esquema de protección identifica las condiciones bajo las cuales el acceso
esta permitido.
6. Adhiérase al principio de privilegio mínimo. Cada proceso debe ejecutarse con el menor conjunto de
privilegios necesarios para completar el trabajo. Cualquier permiso elevado debe mantenerse durante un
tiempo de mamá. Este enfoque reduce las oportunidades que tiene un atacante de ejecutar arbitrarias
código con privilegios elevados.
7. Desinfecte los datos enviados a otros sistemas. Desinfecte todos los datos pasados a subsistemas complejos como
shells de comando, bases de datos relacionales y componentes comerciales listos para usar. Atacantes
puede invocar la funcionalidad no utilizada en estos componentes mediante el uso de SQL,
comando, u otros ataques de inyección. Esto no es necesariamente un problema de validación de entrada.
porque el subsistema complejo que se invoca no comprende el contexto en el que
se hace la llamada. Debido a que el proceso de llamada comprende el contexto, es responsable de desinfectar
los datos antes de invocar el subsistema.
8. Practica la defensa en profundidad. Gestione el riesgo con múltiples estrategias defensivas, de modo que si una capa d
La defensa resulta ser inadecuada, otra capa de defensa puede evitar que se produzca una falla de seguridad.
convertirse en una vulnerabilidad explotable y / o limitar las consecuencias de una explotación exitosa.
Por ejemplo, combinar técnicas de programación seguras con entornos de ejecución seguros
debería reducir la probabilidad de que queden vulnerabilidades en el código en el momento de la implementación
puede explotarse en el entorno operativo.
Página 231
Ciclo de vida del desarrollo del sistema ◾ 205
9. Utilice técnicas eficaces de garantía de calidad. Las técnicas de garantía de buena calidad pueden ser eficaces
tivo en la identificación y eliminación de vulnerabilidades. Pruebas de pelusa , pruebas de penetración y
Las auditorías de código fuente deben incorporarse como parte de un programa de garantía de calidad eficaz.
gramo. Las revisiones de seguridad independientes pueden conducir a sistemas más seguros. Los revisores externos a
una perspectiva independiente, por ejemplo, en la identificación y corrección de supuestos inválidos.
10. Adopte un estándar de codificación seguro. Desarrolle y / o aplique un estándar de codificación seguro para su
lenguaje y plataforma de desarrollo de destino.
Otras prácticas conocidas a las que se hace referencia al desarrollar y asegurar sistemas o aplicaciones
incluir los principios de codificación segura descritos en el Proyecto de seguridad de aplicaciones web abiertas
(OWASP) Pautas de codificación segura. Si bien los principios de codificación segura de OWASP a continuación específicam
aplicaciones Web de referencia, dichos principios también deben aplicarse a aplicaciones que no sean Web. *
1. Validación de entrada
2. Codificación de salida
3. Autenticación y gestión de contraseñas
4. Gestión de sesiones
5. Control de acceso
6. Prácticas criptográficas
7. Manejo y registro de errores
8. Protección de datos
9. Seguridad de las comunicaciones
10. Configuración del sistema
11. Seguridad de la base de datos
12. Gestión de archivos
13. Gestión de la memoria
14. Prácticas generales de codificación
El Instituto de Ingeniería de Software (SEI) también ha desarrollado estándares de codificación US-CERT para
lenguajes de programación comunes como C ++, Java, Perl y la plataforma Android. Incluyen
reglas para desarrollar sistemas seguros, confiables y seguros. Identifican fuentes para el software actual
vulnerabilidades y proporcionar orientación sobre cómo explotarlas. Las descargas de estos estándares son
disponible para la comunidad en línea. †
Pruebas
Las pruebas son, con mucho, la parte más crítica del desarrollo e implementación de cualquier sistema. Sin embargo,
también es el primero en quedar corto cuando se cuestionan las fechas de lanzamiento. El propósito principal de
La prueba del sistema es para validar que el sistema funciona como se esperaba y que identifica errores, fallas,
fallas o fallas en una etapa temprana porque si se descubren más tarde, será costoso repararlas.
Se debe desarrollar una estrategia de prueba general para definir los eventos de prueba, roles y
responsabilidades, entorno de prueba, informes y seguimiento de problemas, y entregables de prueba. los
El proceso de prueba debe basarse en las metodologías de prueba existentes establecidas por la organización.
Un proceso de prueba eficaz permite la documentación que evitará esfuerzos de prueba duplicados.
* https://security.berkeley.edu/secure-coding-practice-guidelines.
† www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards.
Página 232
Debe elaborarse un plan de pruebas de acuerdo con los estándares de la organización. El plan
debe incluir escenarios de prueba, el papel de los participantes de la prueba, los criterios de aceptación y las pruebas
logística. También debe identificar la responsabilidad de la documentación, revisión y aprobación de las pruebas.
y resultados de las pruebas. Los usuarios finales y los propietarios del sistema deben realizar las pruebas necesarias en lugar
programadores o desarrolladores. Deben firmar que se realizaron las pruebas adecuadas con
resultados esperados para todos los requisitos. También se requiere la aprobación de la alta dirección antes de los programas
se promueven a entornos de producción.
Aunque cada sistema puede requerir diferentes eventos de prueba, en general, los eventos de prueba incluyen
pruebas unitarias, pruebas de integración, pruebas técnicas, pruebas funcionales, pruebas de carga de rendimiento
ing y pruebas de aceptación. Las pruebas de aceptación, por ejemplo, verifican que los criterios de aceptación
definidos durante la etapa de definición del sistema. Los casos de prueba deben incluir la usabilidad del sistema
ity, informes de gestión, mediciones de desempeño, documentación y procedimientos, capacitación,
y preparación del sistema (aprobación de operaciones / sistemas). El Anexo 8.2 resume la aceptación del usuario
evento de prueba.
Anexo 8.2 Prueba de aceptación del usuario
Pruebas de aceptación del usuario
Las pruebas de aceptación del usuario (UAT) son clave para el desarrollo exitoso del sistema de aplicaciones y
implementación. Asegura que la aplicación cumpla con los requisitos funcionales acordados.
requisitos (expectativas) de los usuarios, cumple con los criterios de usabilidad establecidos y satisface
directrices de rendimiento antes de su implementación en producción. UAT minimiza la
Riesgos de que el nuevo sistema de aplicaciones cause interrupciones en el negocio o se desvincule de
Procesos de negocios. UAT debe incluir inspecciones, pruebas funcionales y pruebas de carga de trabajo. Eso
debe incluir todos los componentes del sistema de aplicación (por ejemplo, instalaciones, aplicaciones
software, procedimientos, etc.) e implican tener el equipo adecuado, acordar las pruebas
requisitos y obtener la aprobación de los resultados por parte de la gerencia.
Equipo de aceptación
El propietario del proceso debe establecer el equipo de aceptación. El equipo es responsable de

desarrollar e implementar el proceso de aceptación. El equipo de aceptación debe ser
compuesto por representantes de diversas funciones, incluidos los operadores informáticos,
soporte técnico, planificación de capacidad, personal de soporte técnico y administradores de bases de datos.
Requisitos acordados
Los requisitos para UAT deben ser identificados, acordados y priorizados. Aceptación
Los requisitos o criterios deben ser específicos con medidas detalladas. Indirectamente, el
Los requisitos de aceptación se convierten en los criterios para tomar las decisiones de "pasar o no" o
determinar si el sistema de aplicación satisface los requisitos críticos antes de ser
implementado en el entorno en vivo.
Aprobación de la gerencia
Los planes de aceptación y los resultados de las pruebas deben ser aprobados por el departamento funcional afectado
así como el departamento de TI. Para evitar sorpresas, los usuarios deben participar en la aplicación.
pruebas del sistema a lo largo de los procesos de desarrollo e implementación. Esto minimiza
el riesgo de que la funcionalidad clave se excluya o no funcione correctamente.
Página 233
Cada evento de prueba debe tener un plan que defina los recursos del alcance de la prueba (es decir, personas y
ambiente) y objetivos de prueba con los resultados esperados. Deben proporcionar documentación de casos de prueba
y un informe de resultados de la prueba. A menudo es deseable que el usuario final participe en la función
pruebas, aunque todas las pruebas fundamentales mencionadas anteriormente deben aplicarse y documentarse. A
mínimo, la minuciosidad del nivel de prueba debe ser completado y revisado por el
equipo de desarrollo y personal de garantía de calidad. Calidad de las pruebas dentro de cada aplicación y en
la etapa de integración es extremadamente importante.
Los escenarios de prueba, los datos asociados y los resultados esperados deben documentarse para cada condición.
y opción. Los datos de prueba deben incluir datos que sean representativos de escenarios comerciales relevantes,
que pueden ser datos de prueba reales o generados. Independientemente del tipo de datos de prueba elegidos, debe represent
reenviar la calidad y el volumen de datos que se espera. Sin embargo, los controles sobre los datos de producción
utilizados para la prueba deben evaluarse para garantizar que los datos de la prueba no se utilicen incorrectamente o se vean
Las pruebas también deben incluir el desarrollo y generación de informes de gestión. El hombre-
Los informes de gestión generados deben estar alineados con los requisitos comerciales. Los informes deben ser
relevante para asegurar la efectividad y eficiencia del esfuerzo de desarrollo del informe. En general, informe
Las especificaciones deben incluir destinatarios, uso, detalles requeridos y frecuencia, así como el método.
de generación y entrega. El formato del informe debe definirse para que sea claro,
conciso y comprensible. Cada informe debe validarse para garantizar que sea preciso y completo.
plete. Las medidas de control para cada informe deben evaluarse para asegurar que la con-
Los controles se implementan para garantizar la disponibilidad, integridad y confidencialidad. Probar eventos que
pueden ser relevantes, dependiendo del tipo de sistema en desarrollo, se describen en el Anexo 8.3.
Figura 8.3 Eventos de prueba del sistema
Evento de prueba del sistema Descripción
Examen de la unidad Verifica que los programas independientes coincidan con las especificaciones. Casos de prueba
debe ejercitar cada línea de código.
Integración Confirma que todos los componentes de software y hardware funcionan bien
pruebas juntos. Los datos se pasan de forma eficaz de un programa a otro. Todas
Los programas y subrutinas se prueban durante esta fase.
Pruebas tecnicas Verifica que el sistema de aplicación funcione en la producción.

medio ambiente. Los casos de prueba deben incluir el procesamiento y la recuperación de errores,
rendimiento, requisitos de almacenamiento, compatibilidad de hardware y
seguridad (por ejemplo, pantallas, datos, programas, etc.).
Funcional Corrobora que el sistema de aplicación cumple con los requisitos del usuario. Prueba
pruebas Los casos deben cubrir pantallas, navegación, teclas de función, ayuda en línea,
archivos de procesamiento y salida (informes).
Carga de rendimiento Define y prueba las expectativas de rendimiento de la aplicación.

pruebas sistema de antemano. Asegura que la aplicación sea escalable
(funcional y técnicamente), y que se puede implementar sin
interrupción de la organización. Toda la infraestructura debe estar
probado para carga de rendimiento para garantizar la capacidad adecuada y
rendimiento en todos los niveles: procesamiento central, medios de entrada y salida,
redes, etc. El entorno de prueba también debe reflejar el
entorno de producción / vivo tanto como sea posible.
( Continuacion )
Página 234
Figura 8.3 ( continuación ) Eventos de prueba del sistema
Evento de prueba del sistema Descripción
Prueba de caja negra Método de prueba de software que examina el funcionamiento general y
la funcionalidad de un sistema de aplicación sin tener en cuenta su
estructura (por ejemplo, diseño, implementación, rutas internas, etc.). En otra
palabras, los evaluadores no son conscientes de la estructura interna de la aplicación cuando
empleando pruebas de caja negra. Aunque las pruebas de caja negra se aplican
a pruebas de nivel superior, también puede cubrir prácticamente todos los niveles de software
pruebas (es decir, unidad, integración, sistema y aceptación).
Caja blanca Método de prueba de software que va más allá de la interfaz de usuario y
pruebas lo esencial de un sistema. Examina la estructura interna de un
aplicación, en contraposición a sus operaciones y funcionalidad. Contrariamente a
pruebas de caja negra (que se centra en las operaciones de la aplicación y
funcionalidad), las pruebas de caja blanca permiten a los probadores conocer la
estructura interna de la aplicación (p. ej., diseño, implementación,
caminos, etc.) al realizar las pruebas.
Regresión Método de prueba de software que sigue a la implementación de un cambio o

pruebas modificación a un sistema dado. Examina los cambios implementados y
modificaciones realizadas para asegurar que el sistema existente (y su
programación) sigue siendo funcional y funciona de manera eficaz. Una vez
Se han implementado cambios y modificaciones, pruebas de regresión.
vuelve a ejecutar las pruebas existentes contra el código del sistema modificado para garantizar
los nuevos cambios o modificaciones no rompen el trabajo anterior
sistema.
Automatizado Herramientas o técnicas de prueba de software que simplifican el proceso de prueba al

pruebas de software Automatizar la ejecución de pruebas predefinidas en aplicaciones de software.
antes de ser implementado en el entorno de producción.
Pruebas de software automatizadas, como la automatización de pruebas de unidades (p. Ej.,
programa individual, clase, método, función, etc.) que actualmente
exige un uso significativo de los recursos del equipo puede resultar en una mayor
proceso de prueba eficaz y eficiente. Las pruebas de software automatizadas pueden
también compare los resultados de las pruebas actuales con los resultados anteriores.
Software Las pruebas de rendimiento del software son clave para determinar la calidad y
actuación eficacia de una aplicación determinada. El método de prueba determina
pruebas cómo un sistema (es decir, computadora, red, programa de software o dispositivo)
se desempeña en términos de velocidad, capacidad de respuesta y estabilidad bajo un
escenario particular.
Implementación
Esta fase implica el despliegue y la instalación reales del nuevo sistema y su entrega hasta el final.
usuarios. La implementación del sistema verifica que el nuevo sistema cumpla con su propósito previsto y que el
existen procesos y procedimientos necesarios para la producción. Implementar un sistema implica incorporar
evaluar varios controles (es decir, plan de implementación, procedimientos de conversión, desastre / continuidad de TI
Página 235
planes, documentación del sistema, capacitación y soporte) para garantizar una instalación y transición sin problemas
a los usuarios. Para garantizar una implementación sin problemas, también es importante que los usuarios y técnicos
Apoye tanto sea consciente como a bordo con estos controles.
Plan de IMPLEMENTACION
Se debe documentar un plan de implementación para guiar al equipo de implementación y a los usuarios.
en el proceso de implementación. La documentación debe cubrir el calendario de implementación,
los recursos requeridos, roles y responsabilidades del equipo de implementación, medios de
comunicación entre el equipo de implementación y los usuarios, procesos de decisión, gestión de problemas
procedimientos y un plan de capacitación para el equipo de implementación y los usuarios finales. En términos simples, el
El plan debe cubrir quién, qué, cuándo, dónde y cómo del proceso de implementación.
Procesos de conversión y limpieza de datos
A menos que un proceso sea nuevo, la información existente deberá convertirse al nuevo sistema.
La conversión es el proceso en el que la información se ingresa manualmente o se transfiere mediante un programa.
matemáticamente de un sistema antiguo al nuevo. En cualquier caso, la existencia de procedimientos debe
Verificar la conversión de todos los registros, archivos y datos al nuevo sistema para verificar que estén completos y
fines de precisión.
Los procedimientos de conversión de datos pueden caer en uno de los siguientes cuatro reconocidos generalmente
métodos de conversión:
◾ Conversión directa . También conocido como "transferencia directa", es un método de conversión que implica
apagar el sistema actual por completo y cambiar a un nuevo sistema. La organización
básicamente deja de usar el sistema anterior, digamos de la noche a la mañana, y comienza a usar el nuevo el siguient
día y a partir de entonces. Es el método más riesgoso debido a la curva de aprendizaje inmediata.
requerido por los usuarios para interactuar de manera efectiva con el nuevo sistema. Un segundo riesgo sería el
posible mal funcionamiento del nuevo sistema, que afectaría significativamente a la organización
ya que el sistema antiguo ya no está disponible.
◾ Conversión piloto . Método donde se establece un pequeño grupo de usuarios y participantes para
interactuar con el nuevo sistema mientras que el resto sigue utilizando el antiguo / actual. Esta
El método ayuda a las organizaciones a identificar problemas potenciales con el nuevo sistema, por lo que
que se pueden corregir antes de cambiar del anterior. Una vez corregido, el piloto /
El nuevo sistema está instalado para siempre y el antiguo se apaga. Las cadenas minoristas normalmente
beneficiarse de este método. Por ejemplo, instalar un nuevo sistema de punto de venta en una tienda para
fines de prueba y (al funcionar correctamente) implementar el nuevo sistema de trabajo en el
tiendas restantes.
◾ Conversión por fases . También conocido como "conversión modular", es un método que gradualmente
introduce el nuevo sistema hasta que el sistema antiguo sea reemplazado por completo por el nuevo sistema.
Este método ayuda a las organizaciones a identificar problemas al principio de la fase o módulo específico,
y luego programe recursos para corregirlos antes de cambiar al nuevo sistema. Dado
que el sistema actual todavía está parcialmente operativo al implementar este método, el riesgo
tiende a ser relativamente bajo en comparación con otros métodos. En el caso de desempeño inesperado
problemas con el nuevo sistema, el sistema antiguo todavía se puede utilizar ya que todavía está en pleno funcionami
En términos de desventajas, se puede considerar la sustitución gradual del nuevo sistema.
significativo (es decir, la implementación puede llevar más tiempo). Otra desventaja
Página 236
sería la formación, que debe proporcionarse continuamente para garantizar que los usuarios comprendan
el nuevo sistema mientras se está convirtiendo.
◾ Conversión en paralelo . Método que implica ejecutar tanto el sistema antiguo como el nuevo simultáneamente
sólo durante un período de tiempo predeterminado. En este método, los dos sistemas realizan
todo el procesamiento necesario en conjunto y los resultados se comparan en cuanto a precisión e integridad.
Una vez que se han abordado y corregido todos los problemas (si corresponde) y el nuevo sistema funciona correctam
Como era de esperar, el sistema antiguo se apaga y los usuarios comienzan a interactuar simplemente con el nuevo
sistema. La ventaja de este método de conversión es que proporciona redundancia si el
el nuevo sistema no funciona como se esperaba y / o ocurren fallas en el sistema. Cambiando a lo nuevo
El sistema solo se llevará a cabo después de pasar con éxito todas las pruebas necesarias, asegurando que el nuevo
es probable que el sistema funcione según lo diseñado y previsto originalmente. Desventajas comunes
de este método
el doble manejoimplica
de datoslaycarga financiera
operaciones de tenerydos
asociadas, sistemas funcionando
la posibilidad de entrada simultáneamente,
de datos
errores cuando los usuarios ingresan datos en el nuevo sistema.
Un plan de conversión define cómo se recopilan y verifican los datos para la conversión. Antes de la conversión,
los datos deben "limpiarse" para eliminar cualquier inconsistencia que introduzca errores durante la
conversión o cuando los datos se colocan en la nueva aplicación.
Las pruebas que se realizarán durante la conversión de datos incluyen comparar el original y el convertido
registros y archivos, verificando la compatibilidad de los datos convertidos con el nuevo sistema, y
garantizar la precisión y la integridad de las transacciones que afectan a los datos convertidos. Un detallado
La verificación del procesamiento con los datos convertidos en el nuevo sistema debe realizarse para
confirmar la implementación exitosa. Los propietarios del sistema son responsables de garantizar que los datos
convertido con éxito.
El proceso de conversión de datos a menudo se mezcla con la limpieza de datos. La limpieza de datos es una
proceso en el que se embarcan las organizaciones para garantizar que solo se transfieran datos precisos y completos.
ferred en el nuevo sistema. Un ejemplo común son los nombres de empresas en un archivo de proveedor. Una empresa pued
ingresarse en un archivo de proveedor varias veces de múltiples maneras. Por ejemplo, "ABC Manufacturing"
puede ser “ABC mfg”, “abc Mfg.” y así sucesivamente. Muchos de estos cambios en la limpieza de datos se pueden solucion
sistemáticamente porque muchos errores ocurren de manera constante.
El esfuerzo de limpieza de datos debe realizarse antes de ejecutar los procedimientos de conversión de datos. Esto perm
los programadores de conversión para centrarse en convertir los datos en lugar de codificar para datos diferentes
ences. Sin embargo, en realidad, las exenciones de conversión de datos se convierten en problemas para la limpieza de datos
equipo para tratar. Los equipos de conversión y limpieza de datos deben trabajar en estrecha colaboración entre sí
para garantizar que solo se conviertan los datos más precisos y completos. La gerencia debe firmar
desactivado en los resultados de las pruebas para los datos convertidos, así como aprobar los cambios identificados por el eq
Plan de desastre de TI
Este es otro punto de revisión clave para la administración y el auditor de TI. Como parte de la implementación,
Los requisitos para la recuperación del sistema en caso de desastre u otra interrupción deben ser
representaron. El plan de desastres de TI debe revisarse para garantizar que la organización incorpore
Pora los procedimientos y recursos necesarios para recuperar el nuevo sistema de aplicación. Significativo
Las actualizaciones de aplicaciones existentes también pueden requerir modificaciones en los requisitos de recuperación ant
en áreas como requisitos de procesador, almacenamiento en disco o versiones del sistema operativo. Programa de recuperaci
Los procedimientos relacionados con el nuevo sistema deben probarse poco después de su puesta en producción. Tal
Los procedimientos de recuperación también deben estar documentados.
Página 237
En la prisa por implementar un sistema, la documentación puede ser la primera en "deslizarse". Sin embargo, el precio
se paga cuando las decisiones para abordar los problemas se vuelven reaccionarias. Formalizar la documentación y
Los procedimientos son la diferencia entre entregar una tecnología y brindar un servicio. El desastre
El plan de recuperación debe estar en su lugar en el punto de implementación y llevarse a cabo en las operaciones.
Documentación del sistema

La documentación del sistema asegura la mantenibilidad del sistema y sus componentes y minimiza
la probabilidad de errores. La documentación debe basarse en un estándar definido y constar de
descripciones de procedimientos, instrucciones al personal, diagramas de flujo, diagramas de flujo de datos, visualización o
diseños de informes y otros materiales que describen el sistema. La documentación del sistema debe proporcionar
Vide a los programadores con suficiente información para entender cómo funciona el sistema para disminuir la
ciclo de aprendizaje, así como asegurar un análisis eficaz y eficiente de los cambios del programa y
disparo. La documentación debe actualizarse a medida que se modifica el sistema.
La lógica de procesamiento del sistema debe documentarse de manera comprensible.
(por ejemplo, usando diagramas de flujo, etc.), mientras que contiene suficientes detalles para permitir a los programadores
apoyar la aplicación. El software del sistema también debe incluir documentación dentro del código,
con comentarios descriptivos incrustados en el cuerpo del código fuente. Estos comentarios deben
incluir referencias cruzadas a la documentación de diseño y requisitos. La documentación debe
describir la secuencia de programas y los pasos a seguir en caso de una falla de procesamiento.
La documentación del usuario debe incluir flujos de trabajo automatizados y manuales para la capacitación inicial y
referencia continua. Los materiales de referencia del usuario (procesos y procedimientos) deben incluirse como parte
del desarrollo, implementación y mantenimiento de sistemas de aplicaciones asociados. Ellos
deben revisarse y aprobarse como parte de las pruebas de aceptación. Los materiales de referencia del usuario deben
estar diseñado para todos los niveles de experiencia del usuario y debe instruirlos sobre el uso de la aplicación
sistema. Dicha documentación debe mantenerse actualizada a medida que se realicen cambios en los sistemas dependientes.
Formación
La capacitación es un aspecto importante de la implementación de cualquier proyecto. La formación proporciona a los usuar
la comprensión, las habilidades y las herramientas necesarias para utilizar de manera eficaz y eficiente un sistema en su
Tareas. La capacitación es fundamental para ofrecer una implementación exitosa porque presenta a los usuarios
nuevo sistema y les muestra cómo interactuar con él. Ofrecer una formación eficaz involucra a los usuarios,
los motiva a aceptar el cambio y, en última instancia, ayuda a la organización a lograr los objetivos deseados.
resultados comerciales. Por otro lado, el costo de no capacitar a los usuarios puede exceder la inversión
las organizaciones realizarían con fines de formación en el nuevo sistema. Una de las razones de esta paradoja es
que los usuarios pueden tardar más tiempo en aprender el sistema por sí mismos y ser productivos con él.
La formación y la educación eficaces también permiten a las organizaciones obtener beneficios económicos a largo plaz
plazo, reduciendo significativamente los costos de soporte. Esto se debe a que los usuarios cometen menos errores y tienen
haciendo menos preguntas. La formación y la educación junto con una gestión de proyectos eficaz son fundamentales
factores para una implementación exitosa de cualquier sistema.
Apoyo
El apoyo continuo al usuario es otro componente importante necesario para garantizar un éxito
implementación. El soporte incluye tener una mesa de ayuda para brindar asistencia a los usuarios, así como
soluciones de informes de problemas que permiten la presentación, búsqueda y gestión de informes de problemas.
Página 238
El apoyo eficaz implica estrategias para trabajar en estrecha colaboración con los usuarios a fin de garantizar que los problem
resuelto rápidamente, mejorando en última instancia la productividad y la experiencia del usuario.
El soporte de la mesa de ayuda garantiza que los problemas experimentados por el usuario se aborden de manera adecua
Una función de mesa de ayuda debería proporcionar soporte de primera línea a los usuarios. Las solicitudes de ayuda deben
para garantizar que todos los problemas se resuelvan de manera oportuna. Se debe realizar un análisis de tendencias
para identificar patrones en problemas o soluciones. Los problemas deben analizarse para identificar las causas fundamental
Deben existir procedimientos para la escalada de problemas basados en una respuesta inadecuada o un nivel de
impacto. Las preguntas que no puedan resolverse de inmediato deben elevarse a niveles más altos de
gestión o experiencia.
Las organizaciones con mesas de ayuda establecidas necesitarán personal y capacitar al personal de la mesa de ayuda.
para manejar el nuevo sistema de aplicaciones. Un buen entrenamiento minimizará el volumen de llamadas al
mesa de ayuda y así mantener bajos los costos de soporte. Las mesas de ayuda se pueden administrar de manera eficiente co
uso de software de gestión de problemas, sistemas telefónicos automatizados, sistemas expertos, correo electrónico,
correo de voz, etc.
El apoyo continuo al usuario permite a las organizaciones manejar y abordar las solicitudes entrantes de los usuarios en
Moda oportuna y precisa. Por ejemplo, se puede brindar apoyo mediante el establecimiento de un
centro de llamadas (similar a tener una mesa de ayuda) que no solo informa problemas con el nuevo sistema, sino que tambi
encuentra la solución adecuada. Al ayudar a los usuarios en el uso apropiado del nuevo sistema, las organizaciones
puede asegurar una implementación exitosa del sistema.
Operaciones y mantenimiento
No importa qué tan bien esté diseñado, desarrollado y / o probado un sistema, siempre habrá problemas.
descubiertos o mejoras necesarias después de la implementación. En esta fase, los programadores mantienen
sistemas corrigiendo los problemas y / o instalando las mejoras necesarias para
sintonice el nuevo sistema, mejore su rendimiento, agregue nuevas capacidades o conozca a usuarios adicionales
requisitos. El mantenimiento de los sistemas se puede dividir en tres categorías:
◾ Mantenimiento correctivo: implica la resolución de errores, fallas, fallas o fallas en un pro-

gramo o sistema, haciendo que produzca resultados incorrectos o inesperados. Estos son comúnmente
conocidos como "errores". El propósito del mantenimiento correctivo es reparar la funcionalidad existente
para que funcione en lugar de proporcionar una nueva funcionalidad. Este tipo de mantenimiento puede
ocurren en cualquier momento durante el uso del sistema y generalmente es el resultado de pruebas inadecuadas del s
Se puede requerir mantenimiento correctivo para acomodar un nuevo tipo de datos que fueron
excluido inadvertidamente, o para modificar código relacionado con una suposición de un tipo específico de datos
elemento o relación. Como ejemplo de esto último, se asumió en un informe que cada
La solicitud de empleo del empleado tenía una solicitud de empleado (o solicitud de contratación) asociada
atado con él en el sistema. Sin embargo, cuando los usuarios no vieron una lista completa de todos sus
las aplicaciones de los empleados enumeradas, descubrieron que no todas las aplicaciones de los empleados tenían un
solicitud de contratación asociada. En este caso, el requisito de que cada aplicación esté asociada
con una solicitud de contratación se incluyó una nueva función del sistema incluida en la última versión del software.
Como resultado, las aplicaciones de los empleados ingresaron al sistema antes de la instalación del nuevo
La versión no tenía solicitudes de contratación asociadas.
◾ Mantenimiento adaptativo: resultado de cambios normativos y ambientales. los
El propósito del mantenimiento adaptativo es adaptarse o ajustarse a algún cambio en las condiciones comerciales.
en lugar de arreglar las funciones existentes o proporcionar nuevas. Un ejemplo de mantenimiento adaptativo
nance son modificaciones para adaptarse a los cambios en las leyes fiscales. Anualmente, federal y estatal
Página 239
las leyes cambian, lo que requiere cambios en los sistemas financieros y sus informes asociados. Un pasado
ejemplo de este tipo de problema fue el problema del año 2000 (Y2K). Muchos programas de software
fueron escritos para manejar fechas hasta 1999 y fueron reescritos a costos significativos para manejar
fechas que comienzan el 1 de enero de 2000. Aunque estos cambios cuestan a las organizaciones muchos millones
de dólares en esfuerzo de mantenimiento, el objetivo de estos cambios no era proporcionar a los usuarios nuevos
capacidades, sino simplemente para permitir que los usuarios continúen usando los programas de la forma en que está
ellos hoy. Algunas personas argumentan que arreglar el código para acomodarlo al Y2K fue realmente correcto
mantenimiento efectivo, ya que el software debería haber sido diseñado para adaptarse a años más
1999. Sin embargo, debido al costo y las limitaciones del almacenamiento, los sistemas más antiguos usaban dos dígi
representar el año como un medio para minimizar el costo y los límites de almacenamiento.
◾ Mantenimiento
cumplido por el sistemaincluye
perfecto: actual. El objetivo del mantenimiento
la incorporación perfectivodeesusuario
de nuevas necesidades modificar el software
y mejoras para
que no
Apoyar nuevos requisitos. El mantenimiento perfectivo puede ser relativamente simple, como cambiar
el diseño de una pantalla de entrada o la adición de nuevas columnas a un informe. Los cambios complejos pueden
implican una nueva funcionalidad sofisticada. En un ejemplo, una universidad quiso brindar su
estudiantes con la posibilidad de pagar sus cuotas en línea. Un requisito para tal sistema implica
una serie de complejidades, incluida la capacidad de recibir, procesar y confirmar el pago.
Estos requisitos incluyen requisitos adicionales, como la capacidad de proteger la información
mación y proteger al estudiante y la institución manteniendo la integridad de los datos y
información. Junto con esto, son necesarios requisitos adicionales para proteger el proceso.
en su capacidad para recuperar y continuar el procesamiento, así como la capacidad para validar, verificar y
auditar cada transacción.
Se debe establecer un sistema de informes para que los usuarios informen de los problemas del sistema y / o
a los programadores y, a su vez, los programadores se comunican con los usuarios cuando
han sido arreglados o atendidos. Dicho sistema de informes debería constar de pistas de auditoría para
problemas, sus soluciones y mejoras realizadas. El sistema debe documentar la resolución,
oritización, procedimientos de escalamiento, informes de incidentes, accesibilidad a la configuración, información
la coordinación con la gestión del cambio y una definición de las dependencias de los servicios externos,
entre otros.
Los sistemas de informes deben garantizar que todos los eventos inesperados, como errores, problemas, etc.
registrados, analizados y resueltos de manera oportuna. Los informes de incidentes deben establecerse en el
caso de problemas importantes. También deben existir procedimientos de escalada para garantizar que los problemas
se resuelven de la manera más oportuna y eficiente posible. Los procedimientos de escalamiento incluyen priorización
problemas basados en la gravedad del impacto, así como la activación de un plan de continuidad del negocio
cuando sea necesario. Un sistema de informes que también está estrechamente asociado con el cambio de la organización.
El proceso de gestión es esencial para garantizar que se resuelvan los problemas o se realicen mejoras.
y, lo más importante, para evitar que vuelvan a ocurrir.
El mantenimiento de un sistema también requiere mantener actualizada la documentación relacionada con el nuevo
sistema. La documentación se crea en cada fase del SDLC. Se puede crear documentación del sistema
como diagramas de flujo, gráficos, tablas o texto para organización y facilidad de lectura. Documentación del sistema
incluye:
◾ Fuente de los datos

◾ Atributos de datos
◾ Pantallas de entrada
◾ Validaciones de datos
Página 240
◾ Criterios de selección de datos

◾ Procedimientos de seguridad
◾ Descripción de cálculos
◾ Diseño de programas
◾ Interfaces con otras aplicaciones
◾ Procedimientos de control
◾ Manejo de errores
◾ Instrucciones de funcionamiento
◾ Archivar, depurar y recuperar
◾ Copia de seguridad, almacenamiento y recuperación
Existe una correlación definida entre un proceso de desarrollo de un sistema bien gestionado y un éxito
sistema. Un proceso de desarrollo del sistema proporciona un entorno propicio para el éxito del sistema.
desarrollo de tems. Dicho proceso aumenta la probabilidad de que un nuevo sistema tenga éxito y
sus controles internos serán efectivos y confiables.
Riesgos adicionales y controles asociados relacionados

a las Fases SDLC
Riesgos adicionales atribuibles a las fases de SDLC que acabamos de comentar, y que son importantes para la
organización y el auditor de TI se enumeran a continuación. Estos pueden resultar en datos inválidos o engañosos,
evitó los controles automatizados y / o el fraude.
◾ Desarrolladores o programadores con acceso no autorizado para promover información incorrecta o

priar cambios en datos, programas de aplicación o configuraciones en el proceso de producción
medio ambiente.
◾ Los cambios en aplicaciones, bases de datos, redes y sistemas operativos no se autorizan correctamente.
rizado y / o sus pruebas no se realizan adecuadamente antes de la implementación en el
entorno de producción.
◾ Cambie los procedimientos de gestión relacionados con aplicaciones, bases de datos, redes y operaciones
Los sistemas son inadecuados, ineficaces o inconsistentes, lo que afecta la estabilidad o la manera en
qué datos se procesan en el entorno de producción.
◾ Los controles y procedimientos existentes relacionados con la conversión de datos son inexistentes, inadecuados,
o ineficaz, lo que afecta la calidad, estabilidad o forma en que se procesan los datos
dentro del entorno de producción.
Los controles y procedimientos de TI relevantes para evaluar el proceso SDLC que acabamos de discutir incluyen asegurar
ese:
◾ La gerencia evalúa los riesgos comerciales y el impacto de los cambios propuestos en el sistema.
antes de la implementación en entornos de producción. Los resultados de la evaluación se utilizan cuando
diseñar, dotar de personal y programar la implementación de cambios para minimizar las interrupciones
ciones a las operaciones.
◾ Las solicitudes de cambios en el sistema (por ejemplo, actualizaciones, arreglos, cambios de emergencia, etc.) se
documentado y aprobado por la dirección antes de realizar cualquier trabajo relacionado con el cambio.
◾ La documentación relacionada con la implementación del cambio es precisa y completa.
Página 241
Ciclo de vida de desarrollo del sistema ◾ 215
◾ La documentación de cambios incluye la fecha y hora en las que los cambios fueron (o serán)
instalado.
◾ Se ha publicado y comunicado la documentación relacionada con la implementación del cambio
a los usuarios del sistema.
◾ Los cambios del sistema se prueban con éxito antes de su implementación en el entorno de producción.
◾ Planes de prueba y casos que involucren datos de prueba completos y representativos (en lugar de
datos) son aprobados por los propietarios de la aplicación y la gestión de desarrollo.
En el Apéndice 3 del Capítulo 3 se muestran controles adicionales sobre el proceso de control de cambios.
El apéndice enumera los controles aplicables a la mayoría de las organizaciones que se consideran procedimientos de orienta
tanto, gestión de TI y auditores de TI.
Enfoques para el desarrollo de sistemas

Hay varios enfoques aplicables al desarrollo de sistemas. Aunque cada enfoque es único,
todos tienen pasos similares que deben completarse. Por ejemplo, cada enfoque tendrá que definir
requisitos del usuario, diseñar programas para cumplir con esos requisitos, verificar que los programas funcionen como
previsto e implementar el sistema. Los auditores de TI deben comprender los diferentes enfoques, la
riesgos asociados con el enfoque particular, y ayudar a garantizar que todos los componentes necesarios
(controles) están incluidos en el proceso de desarrollo. A continuación se presentan descripciones de sistemas comunes
Enfoques de desarrollo tem a partir del método tradicional de desarrollo del sistema en cascada.
Otros métodos modernos y no secuenciales, como metodologías ágiles y ligeras (p. Ej.,
También se discuten Scrum, Kanban, Extreme Programming (XP), etc.).
Desarrollo del sistema de cascada

El enfoque en cascada (también conocido como método tradicional) para el desarrollo de sistemas es un
proceso secuencial con fases definidas que comienzan con la identificación de una necesidad y terminan con
implementación del sistema. El enfoque tradicional utiliza un SDLC estructurado que proporciona una
marco para la planificación y desarrollo de sistemas de aplicación. Aunque hay muchas variaciones de
este método tradicional, todos tienen las siete fases comunes que acabamos de discutir: Planificación, Sistema
Análisis y requisitos, diseño de sistemas, desarrollo, pruebas, implementación y operaciones
y mantenimiento. Consulte el Cuadro 8.4 para ver una ilustración del enfoque de desarrollo Waterfall.
Aunque el proceso de desarrollo en cascada proporciona estructura y organización a los sistemas
desarrollo, no está exento de riesgos. El enfoque en cascada puede ser un largo proceso de desarrollo.
eso es costoso debido a la cantidad de recursos y el tiempo requerido. El entorno empresarial
El mecanismo puede cambiar entre el momento en que se definen los requisitos y el momento en que se implementa el sistem
mentado. Los usuarios pueden tener una gran demora antes de ver cómo se verá y se sentirá el sistema. A
compensar estos desafíos, un proyecto se puede dividir en subproyectos más pequeños donde
Los módulos están diseñados, codificados y probados. El desafío en este enfoque es llevar todos los módulos
juntos al final del proyecto para probar e implementar el sistema completamente funcional.
Desarrollo de sistemas ágiles

Las prácticas de desarrollo de sistemas ágiles están transformando el negocio de crear y / o mantener
mantener los sistemas de información. Ágil significa capaz de moverse rápida y fácilmente. El sistema ágil
Página 242
Planificación
Análisis del sistema y

requisitos
Diseño de sistemas
Desarrollo
Pruebas
Implementación
Operaciones y
mantenimiento
Figura 8.4 Desarrollo del sistema de cascada.
La metodología de desarrollo (ASD) se utiliza en proyectos que necesitan extrema agilidad en los requisitos
(por ejemplo, para entregar productos al cliente de forma rápida y continua, etc.). ASD se centra en el
adaptabilidad a situaciones cambiantes y retroalimentación constante. Con TEA, no hay una definición clara
producto final en la etapa inicial. Esto es contrario al enfoque tradicional en cascada, que
requiere que se establezcan requisitos detallados del producto final en la fase inicial. Características clave de ASD
implican ciclos de entrega a corto plazo (o sprints), requisitos ágiles, una cultura de equipo dinámica, menos
control restrictivo del proyecto y énfasis en la comunicación en tiempo real. Aunque el TEA es más
comúnmente utilizado en proyectos de desarrollo de software, el enfoque también puede ayudar a otros tipos de
proyectos. El enfoque ASD suele ser una buena opción para proyectos de software relativamente más pequeños o
proyectos con cronogramas de desarrollo acelerados. Consulte el Anexo 8.5 para ver una ilustración de la
Enfoque de desarrollo ágil.
Las prácticas ágiles son cada vez más utilizadas por la industria. En un estudio realizado por Protiviti en 2016, el 44%
de las empresas en general, incluido el 58% de las empresas de tecnología y el 53% de los productos de consumo
y minorista, estaban invirtiendo y adoptando estas prácticas. Por tanto, es seguro concluir que ASD
seguirá siendo una práctica estándar para un porcentaje significativo de funciones de TI. TEA común
Las metodologías incluyen Scrum, Kanban y Extreme Programming, y se discuten a continuación.
1. Scrum . Un derivado del enfoque ASD, Scrum es un software iterativo e incremental

marco de desarrollo para gestionar el desarrollo de productos. Su principal objetivo es involucrar a un
estrategia de desarrollo de productos flexible y holística que mejora la productividad al permitir pequeños,
Los equipos multifuncionales y autogestionados trabajan como una unidad para alcanzar un objetivo común. Como u
enfoque iterativo / ágil, Scrum promueve varias "sesiones" (también denominadas "sprints"),
que normalmente duran 30 días. Estas sesiones promueven la priorización de tareas y aseguran
se completan de manera oportuna. Debido a esto, los equipos que cambian a Scrum tienden a
Página 243
comienzo
Plan
Evaluar y Sistema
proporcionar análisis y
retroalimentación requisitos
Ágil
sistema
desarrollo
Diseño y
Implementar
desarrollar
Desplegar
Integrar y
prueba
Figura 8.5 Desarrollo de sistemas ágiles.
ver grandes ganancias en productividad. El gerente de proyectos de Scrum se conoce como Scrum Master. los
La principal responsabilidad de Scrum Master es permitir las comunicaciones diarias del proyecto y tratar
distracciones entre los miembros del equipo que impiden la finalización satisfactoria del trabajo en cuestión.
El Scrum Master lleva a cabo reuniones periódicas con los equipos para discutir el estado, el progreso,
resultados y cronogramas, entre otros. Estas reuniones también son muy útiles para identificar
nuevas tareas o las existentes que necesitan ser re-priorizadas. Scrum es aplicable en ciertos tipos
de entornos, particularmente aquellos con miembros ubicados en la misma ubicación física
donde la colaboración cara a cara entre los miembros del equipo es posible y se practica (es decir,
equipos coubicados).
2. Kanban . Kanban es también un tipo de metodología ágil que se utiliza para aumentar la visibilidad de la
trabajo de desarrollo real, lo que permite una mejor comprensión del flujo de trabajo, así como una rápida
identificación de su estado y progreso. Visualizar el flujo de trabajo también es útil para
Equilibrar la demanda con la capacidad disponible. Con Kanban, desarrollo de elementos de trabajo y tareas
se muestran para proporcionar a los miembros del equipo una mejor idea de "lo que está pasando" y "lo que queda po
terminar." Los diagramas o gráficos Kanban también se utilizan normalmente para representar categorías generales de
actividades o tareas, como "actividades en curso", "actividades en cola" o "actividades que
se acaban de completar ". Esta visualización permite a los miembros del equipo, incluida la administración
personal, para ver el trabajo actual y lo que queda por completar; volver a priorizar si es necesario; y
evaluar el efecto de tareas adicionales de última hora en caso de que se requiera su incorporación.
Kanban se centra en el trabajo real de pequeños equipos de proyectos que comparten el mismo lugar que en
actividades de los individuos (aunque muchos individuos también promueven el uso de Kanban personales
tableros). Se argumenta que Kanban expone (visualiza) problemas operacionales temprano y estimula
Última colaboración para corregirlos y mejorar el sistema. Hay seis prácticas generales
utilizado en Kanban: visualización, limitación del trabajo en curso, gestión del flujo, elaboración de políticas
explícito, utilizando ciclos de retroalimentación y evolución colaborativa o experimental.
3. Programación extrema . Extreme Programming (XP) es otro tipo de desarrollo de software ágil
metodología de operación destinada a mejorar la productividad y la calidad tomando
Página 244
Prácticas y elementos básicos de la ingeniería de software a niveles “extremos”. Por ejemplo, incor-
porar puntos de control de revisión de código continuo (en lugar de tener solo los tradicionales,
revisión de código solo por tiempo) en la que se pueden evaluar, agregar y
procesada. Otro ejemplo de alcanzar niveles "extremos" sería la implementación de
pruebas automatizadas (tal vez dentro de los módulos de software) para validar la operación y la función
alidad de pequeñas secciones del código, en lugar de probar solo las características más grandes. El objetivo de XP es
para aumentar la capacidad de respuesta de una organización de software al tiempo que disminuye la sobrecarga de d
Similar a Scrum y otros métodos ágiles, XP se enfoca en entregar código ejecutable y
utilizar al personal de forma eficaz y eficiente durante todo el proceso de desarrollo de software.
XP enfatiza en la retroalimentación de escala fina, el proceso continuo, la comprensión compartida y la
bienestar grammer.
Desarrollo de software adaptativo

El desarrollo de software adaptativo (ASWD) es un enfoque de desarrollo diseñado para construir
software y sistemas complejos. Se centra en la rápida creación y evolución de sistemas de software.
(es decir, consistente con el principio de adaptación continua). ASWD sigue un ciclo de vida dinámico
cle en lugar del tradicional ciclo de vida estático Plan-Diseño-Construcción . Se caracteriza por constantes
cambio, reevaluación, así como mirar hacia un futuro incierto y una intensa colaboración entre
desarrolladores, probadores y clientes.
ASWD es similar al enfoque de desarrollo rápido de aplicaciones. Reemplaza el tradicional
ciclo en cascada con una serie repetida de ciclos de especulación, colaboración y aprendizaje. Estas dinámicas
Los ciclos proporcionan un aprendizaje continuo y una adaptación al estado emergente del proyecto. Durante
Estos ciclos o iteraciones, el conocimiento resulta de cometer pequeños errores basados en suposiciones falsas
(especular), reorganizar equipos para trabajar juntos en la búsqueda de una solución (colaborar) y
finalmente corregir (y dominar) esos errores (aprender), lo que lleva a una mayor
experiencia y finalmente dominio en el dominio del problema. Consulte el Anexo 8.6 para ver una ilustración.
del enfoque ASWD.
Desarrollo de aplicaciones conjuntas

El desarrollo de aplicaciones conjuntas (JAD) es un enfoque o metodología desarrollado a fines de la década de 1970
que implica la participación del cliente o del usuario final en las etapas de diseño y desarrollo
de un sistema de información, a través de una sucesión de talleres colaborativos denominados sesiones JAD.
A través de estas sesiones de JAD, los usuarios finales, clientes, personal comercial, auditores de TI, especialistas en TI y
otros técnicos, entre otros, son capaces de resolver sus dificultades o diferencias relativas
1. Especula
3. Aprenda 2. Colabora
Figura 8.6 Desarrollo de software adaptativo.
Página 245
Sesión JAD - Diseño y desarrollo de sistemas de información
Sesiones o trabajo
tiendas realizadas
por una instalación JAD
tator para discutir
diseño del sistema
y desarrollo.
Los participantes pueden

incluir:
Cliente, usuario final
Representa-
tiva (s), ES Ana-
lyst (s), Negocios
Analista (s), SI
Gerente, Sys-
arquitecto de tems
Arquitecto de datos,
Auditores de TI, etc.
Figura 8.7 Diseño / desarrollo de aplicaciones conjuntas.
el nuevo sistema de información. Las sesiones siguen una agenda detallada para evitar errores
comunicaciones, así como para garantizar que todas las incertidumbres entre las partes estén cubiertas.
Las malas comunicaciones pueden tener repercusiones mucho más graves si no se abordan hasta más adelante en el
proceso.
El enfoque JAD conduce a tiempos de desarrollo más rápidos y una mayor satisfacción del cliente que el
enfoque tradicional porque el cliente está involucrado en todo el diseño y desarrollo
procesos de ment. En el enfoque tradicional, por otro lado, el desarrollador investiga el
requisitos del sistema y desarrolla una aplicación con la entrada del cliente que generalmente consta de una
entrevista.
Una variación de JAD es la creación de prototipos y el desarrollo rápido de aplicaciones, lo que crea aplicaciones
en tiempos más rápidos a través de estrategias, como usar menos metodologías formales y reutilizar software
componentes. Al final, JAD da como resultado un nuevo sistema de información que es factible y atractivo para
tanto el cliente como los usuarios finales. Consulte la figura 8.7 para ver una ilustración del enfoque JAD.
Creación de prototipos y desarrollo rápido de aplicaciones

En general, la creación de prototipos y el desarrollo rápido de aplicaciones (RAD) incluye:
◾ la transformación y diseño rápido de los requisitos básicos del usuario en un modelo de trabajo
(es decir, prototipo);
◾ la construcción del prototipo;
◾ la revisión y mejora del prototipo; y
◾ la decisión de aceptar el prototipo como simulación final del sistema real
(por lo tanto, no se necesitan más cambios), o volver a rediseñar y trabajar con el usuario
requisitos.
La figura 8.8 ilustra este proceso de creación de prototipos y RAD.
Página 246
Reúna los requisitos del usuario
Transformar requisitos
y diseño rápido
Construir prototipo
Revisar y mejorar
prototipo
Cambios? si
No
Implementar e implementar
Figura 8.8 Proceso de creación de prototipos y RAD.
La creación de prototipos y RAD pueden facilitar la interacción entre los usuarios, los analistas de sistemas y el departam
auditor. Estas técnicas se pueden aplicar al desarrollo de informes de producción, una aplicación específica
módulo, o todo el sistema de soporte. Algunas ventajas de la creación de prototipos y RAD incluyen:
◾ Los prototipos se pueden ver y analizar antes de comprometer una gran financiación para los sistemas.
◾ La aprobación del usuario y la satisfacción final se mejoran debido a una mayor participación en el
diseño del proyecto.
◾ El costo de modificar los sistemas se reduce porque los usuarios y diseñadores pueden prever problemas
antes y son capaces de responder al entorno empresarial rápidamente cambiante de los usuarios.
◾ Un prototipo rudimentario se puede rediseñar y mejorar muchas veces antes de la forma final.
es aceptado.
◾ Muchos sistemas están diseñados “desde cero” y no existe ningún sistema actual que sirva de guía.
Por otro lado, debido a que los prototipos parecen ser definitivos cuando se presentan a los usuarios, el programa
Es posible que los usuarios no dispongan del tiempo suficiente para completar el sistema e implementar el prototipo
producto final. A menudo, el usuario intentará utilizar el prototipo en lugar del sistema de entrega completo.
El usuario debe comprender que el prototipo no es un sistema completo. Riesgos asociados con
la creación de prototipos y RAD incluyen:
◾ Diseño de sistema incompleto

◾ Rendimiento de procesamiento ineficiente
◾ Controles de aplicación inadecuados
◾ Documentación inadecuada
◾ Implementaciones ineficaces
Desarrollo de software ajustado

El desarrollo de software ajustado (LSD) es una traducción de los principios de fabricación ajustada y TI ajustada
y prácticas para el dominio del desarrollo de software. El LSD es un tipo de enfoque ágil que puede
Página 247
resumidos en siete principios clave, que son muy cercanos en concepto a los principios de manufactura esbelta
principios. Son:
1. Elimine el desperdicio: identifique lo que crea valor para el cliente

2. Incorporar la calidad: integrar la calidad en el proceso; prevenir defectos
3. Crear conocimiento: investigar y corregir errores a medida que ocurren; desafiar y mejorar
estándares; aprender de los errores
4. Difiera el compromiso: aprenda constantemente; actuar solo cuando sea necesario y rápido
5. Entregue lo más rápido posible: entregue valor al cliente rápidamente; alta calidad y bajo costo
6. Capacite al equipo y respete a las personas: involucre a todos; construir integridad; proporcionar un ambiente estable
7. Optimice el todo: entregue un producto completo; monitorear la calidad; mejora continua
Consulte el Cuadro 8.9 para ver una ilustración del enfoque LSD.
Desarrollo del usuario final

El desarrollo del usuario final (EUD) (también conocido como computación del usuario final) se refiere a aplicaciones que s
creado, operado y mantenido por personas que no son desarrolladores de software profesionales (fin
usuarios). Son muchos los factores que han llevado al usuario final a construir sus propios sistemas. Primero y
probablemente el más importante, es el cambio en la tecnología hacia computadoras personales (PC) y generación
lenguajes de programación (por ejemplo, lenguajes de cuarta generación [4GL], 5GL, etc.). Este cambio tiene
debido, en parte, a la disminución de los costos de hardware y software que han permitido a las personas
propias computadoras. Debido a esto, las personas se han vuelto más alfabetizadas en informática. Al mismo
tiempo, los usuarios se sienten frustrados por el tiempo que lleva el desarrollo de sistemas tradicionales
esfuerzos por completar. Los lenguajes de programación de cuarta generación, por ejemplo, han proporcionado
usuarios con las herramientas para crear sus propias aplicaciones. Ejemplos de tales herramientas incluyen:
1. Eliminar
residuos
7. Optimizar 2. Construir
todo calidad
6. Empoderar 3. Crear
equipo conocimiento
5. Entregar 4. Aplazar
rápido compromiso
Figura 8.9 Desarrollo de software ajustado.
Página 248
◾ Herramientas de consulta basadas en mainframe que permiten a los usuarios finales desarrollar y mantener informes. E
incluye lenguajes de cuarta generación como EZ-TRIEVE y SAS o programador
desarrolló aplicaciones de generación de informes utilizando lenguajes de consulta.
◾ Paquetes de proveedores que automatizan un proceso comercial genérico. Esto incluye paquete de contabilidad
edades para generar estados financieros y paquetes legales para la gestión de casos.
◾ Aplicaciones EUD que utilizan herramientas basadas en PC, bases de datos u hojas de cálculo para cumplir con un dep
necesidad de procesamiento de información individual.
Debido a que las PC parecen relativamente simples y se perciben como herramientas de productividad personal, su efecto en
una organización ha sido ignorada en gran medida. En muchas organizaciones, las aplicaciones de EUD tienen limitaciones
o sin procedimientos formales. Es posible que los usuarios finales no tengan los conocimientos previos para desarrollar aplic
ciones con controles adecuados o mantenibilidad. Esto se convierte en un problema cuando las organizaciones confían en
sistemas desarrollados por el usuario para las operaciones diarias y la toma de decisiones importantes. Simultaneamente,
Los sistemas de usuario final son cada vez más complejos y se distribuyen entre plataformas y organizaciones.
fronteras nacionales. Algunos de los riesgos asociados con las aplicaciones de EUD incluyen los siguientes.
◾ Mayores costos organizacionales

◾ Sistemas incompatibles
◾ Sistemas redundantes
◾ Ausencia de segregación de funciones
◾ Análisis del sistema incompleto
◾ Acceso no autorizado a datos o programas
◾ Violaciones de derechos de autor
◾ Destrucción de información por virus informáticos
◾ Falta de opciones de respaldo y recuperación
La figura 8.10 resume el enfoque de EUD para el desarrollo de sistemas.
Desarrollo del usuario final

(EUD) promueve una cultura
de la participación del usuario y
participación.
Se crean sistemas EUD,

operado y mantenido por
personas que no son profesio-
desarrolladores de software sional
(es decir, usuarios finales).
Las aplicaciones de EUD tienen límites

ited o sin procedimiento formal
duros y riesgos resultantes
de los usuarios finales que no tienen
el conocimiento previo
para desarrollar aplicaciones con
controles y mantenimiento adecuados
sostenibilidad.
Figura 8.10 Desarrollo del usuario final.
Página 249
Participación del auditor de TI en el desarrollo del sistema

e implementación
Los auditores de TI pueden ayudar a las organizaciones revisando el desarrollo y la implementación de sus sistemas.
(SD&I) para asegurar que los nuevos sistemas cumplan con la estrategia y los estándares de la organización.
Cada proyecto de SD&I deberá evaluarse los riesgos para determinar el nivel de participación de la auditoría. los
El tipo de revisión también variará dependiendo de los riesgos de un proyecto en particular. Los auditores de TI solo pueden
involucrados en áreas clave o en todo el proyecto SD&I. En cualquier caso, los auditores de TI deben comprender
controles de procesos y aplicaciones para agregar valor y asegurar que los controles adecuados estén integrados en el sistem
Se realizan auditorías de SD&I para evaluar los controles administrativos sobre la autorización,
desarrollo e implementación de nuevos sistemas (es decir, aplicaciones), y para revisar el diseño de
los controles / pistas de auditoría del sistema propuesto. El alcance de una auditoría de SD&I incluye una evaluación
del enfoque o metodología general de SDLC. La auditoría también se centra en la evaluación de la
calidad de los entregables de cada fase de desarrollo del sistema (por ejemplo, evaluación de los controles
diseño y pistas de auditoría, plan de prueba del sistema y resultados, formación de usuarios, documentación del sistema, etc.
Las recomendaciones de las auditorías de SD&I pueden incluir mejoras en los requisitos del usuario, aplicaciones
controles de seguridad, o la necesidad de documentar los planes de prueba y los resultados esperados de la prueba.
Desarrollar e implementar nuevos sistemas puede ser una tarea costosa y que requiere mucho tiempo. UN
Un entorno bien controlado con una estrategia general, estándares, políticas y procedimientos ayuda
asegurar el éxito de los esfuerzos de desarrollo. Hay muchos procesos que deben controlarse bien
para asegurar el éxito general de un sistema. Debido al costo significativo de implementar controles después
un sistema ya ha entrado en producción, se deben definir controles antes de construir un sistema.
Existen muchas oportunidades para la participación del auditor en el proceso de SD&I. Los auditores de TI necesitan
desarrollar las habilidades y las relaciones para trabajar con el equipo de SD&I para asegurar que los controles sean
integrado en el sistema. Los auditores de TI pueden ayudar a las organizaciones al:
◾ revisar el entorno de SD&I

◾ evaluar los estándares para SD&I
◾ evaluar las fases en el proceso de SD&I
◾ revisar los sistemas críticos de entrada, procesamiento y salida
◾ verificar que el nuevo sistema proporciona una pista de auditoría adecuada
El papel del auditor de TI en un proyecto de SD&I depende de la cultura de la organización, la madurez del SI
función y filosofía del departamento de auditoría. La auditoría de SD&I requiere conocimientos específicos
sobre el proceso (es decir, el desarrollo y la implementación) y los controles de la aplicación. Comprensión
El proceso permite al auditor identificar áreas clave que se beneficiarían de una verificación independiente.
ción. Comprender los controles de la aplicación permite al auditor evaluar y recomendar controles.
para garantizar un procesamiento de transacciones completo y preciso.
Los auditores de TI pueden asumir dos roles diferentes en un proyecto de SD&I: consultor de control o
revisor de abolladuras.
◾ Como consultor de control, el auditor se convierte en miembro del equipo de SD&I y trabaja con
analistas y programadores para diseñar controles de aplicaciones. En este rol, el auditor no es
más independiente del equipo de SD&I.
◾ Como revisor independiente, el auditor no tiene responsabilidades de diseño y no informa
al equipo, pero puede proporcionar recomendaciones para que el proyecto / sistema actúe o no
gerente.
Página 250
Al involucrarse en puntos estratégicos, el auditor puede asegurarse de que un sistema esté bien controlado
y auditable. A continuación se destacan algunas de las responsabilidades clave del auditor cuando
involucrado en un proyecto SD&I:
1. Revise los requisitos del usuario

2. Revisar los controles manuales y de la aplicación
3. Verifique que todas las especificaciones técnicas cumplan con los estándares de la empresa.
4. Realice recorridos de diseño al final de cada fase de desarrollo.
5.
6. Envíe recomendaciones
Asegurar por escrito
la implementación para su aprobaciónantes
de las recomendaciones después de cada recorrido.
de comenzar la siguiente fase.
7. Revisar los planes de prueba.
8. Presentar los hallazgos a la gerencia
9. Mantener la independencia para seguir siendo objetivo
Estos pueden ayudar a minimizar las debilidades y problemas de control antes de que el sistema se implemente en
producción y se vuelve operativo en lugar de después de su uso.
Los auditores de TI determinan su nivel de participación en una auditoría de SD&I completando una evaluación de riesg
mento del proceso SD&I. Los resultados de la evaluación de riesgos también indican la cantidad de tiempo
necesarios para asignar al proyecto en particular, recursos requeridos, etc. Preparación de un plan de auditoría
sigue. El plan describe los objetivos y procedimientos de auditoría que se realizarán en cada fase de
el proceso SD&I. Los auditores de TI comunican no solo el alcance de su participación, sino también
hallazgos y recomendaciones para el personal de desarrollo, los usuarios y la gerencia como resultado de
la auditoría.
Es posible que los auditores de TI no tengan suficiente tiempo para participar en todas las fases de cada proyecto de SD&I.
La participación dependerá de la evaluación de los riesgos del proceso y la aplicación. Los riesgos del proceso pueden
incluyen clima organizacional negativo, así como la falta de dirección estratégica, desarrollo
estándares, y de un proceso formal de desarrollo de sistemas. Riesgos de aplicación, por otro lado,
relacionarse con la complejidad y magnitud de la aplicación; personal sin experiencia; falta de participación del usuario fina
y falta de compromiso de la dirección.
El nivel de riesgo puede estar en función de la necesidad de información oportuna, la complejidad de la aplicación
cación, grado de confianza para decisiones importantes, tiempo de uso de la aplicación, y
la cantidad de personas que lo usarán.
La evaluación de riesgos define qué aspectos de un sistema o aplicación en particular están cubiertos
por la auditoría. Dependiendo del riesgo, el alcance de la evaluación puede incluir el sistema de evaluación
requisitos, así como la revisión de los entregables de diseño y prueba, controles de aplicación,
controles, seguridad, gestión de problemas, controles de cambios o la fase posterior a la implementación.
Plan de auditoria
Los auditores de TI pueden participar en el proceso de planificación de un proyecto de SD&I con el fin de: desarrollar un
comprensión del sistema propuesto; asegurarse de que se incluya tiempo en el cronograma para definir los controles;
y verificar que estén involucradas todas las personas adecuadas. El plan de auditoría también detallará los pasos y el pro-
procedimientos para cumplir los objetivos de la auditoría. Como en cualquier auditoría, una auditoría de SD&I comienza con
análisis del entorno de control mediante la revisión de normas, políticas y procedimientos existentes.
Página 251
Durante la auditoría, estos estándares, políticas y procedimientos deben evaluarse para verificar que estén completos.
y eficiencia operativa. El análisis preliminar debe identificar la estrategia de la organización y
las responsabilidades de gestión y control de aplicaciones.
El plan de auditoría documentará además los procedimientos necesarios para revisar el proceso de SD&I para
asegurarse de que el sistema esté diseñado de acuerdo con los requisitos del usuario, que la dirección apruebe
dicho diseño, y que el sistema o la aplicación se prueban adecuadamente antes de la implementación. Un
El enfoque adicional del plan de auditoría es asegurarse de que el usuario final pueda utilizar el sistema.
basado en una combinación de habilidades y documentación de respaldo.
Una auditoría de SD&I evalúa la idoneidad del entorno de control para desarrollar
sistemas para proporcionar una seguridad razonable de que se realizan las siguientes tareas:
◾ Cumplir con los estándares, políticas y procedimientos

◾ Logre operaciones eficientes y económicas
◾ Conforme los sistemas a los requisitos legales
◾ Incluya los controles necesarios para proteger contra pérdidas o errores graves
◾ Proporcionar controles y pistas de auditoría necesarios para la administración, el auditor y para la revisión operativa.
propósitos
◾ Documentar una comprensión del sistema (también necesario para el mantenimiento y
revisión de cuentas)
Para cualquier tipo de asociación que involucre auditores de TI, usuarios y administración de SI, es importante que
la organización planifica y establece un procedimiento formal para el desarrollo e implementación
ción de un sistema. La influencia del auditor aumenta significativamente cuando existen procedimientos formales y
pautas requeridas que identifican cada fase y entrega del proyecto en el SDLC y el alcance de
participación del auditor. Sin procedimientos formales de SDLC, el trabajo del auditor es mucho más difícil y
las recomendaciones pueden no ser aceptadas tan fácilmente. Los procedimientos formales establecidos permiten a los audit
◾ Revise todas las áreas y fases relevantes del SDLC

◾ Identificar las áreas que faltan para el equipo de desarrollo
◾ Informar de forma independiente a la dirección sobre el cumplimiento de los objetivos y procedimientos planificados
◾ Identificar partes seleccionadas del sistema e involucrarse en los aspectos técnicos basados en
sus habilidades y habilidades
◾ Proporcionar una evaluación de los métodos y técnicas aplicados en el proceso de SD&I, como
definido antes
El plan de auditoría también debe documentar las actividades y responsabilidades (tareas) del auditor a realizar.
formados dentro de cada fase restante de SD&I (es decir, análisis y requisitos del sistema,
Diseño, Desarrollo, Pruebas, Implementación y Operaciones y Mantenimiento). Estos son
descrito abajo.
Tarea de auditor: análisis y requisitos del sistema

El equipo del proyecto normalmente dedica un esfuerzo considerable al análisis del problema empresarial.
y lo que el sistema debe producir sin intentar inicialmente desarrollar el diseño del sistema.
El auditor de TI debe observar que la responsabilidad principal no es desarrollar un producto sino
satisfacer al usuario. A menudo, el usuario no comprende lo que realmente se necesita. Solo entendiendo
el negocio del usuario, sus problemas, metas, limitaciones, debilidades y fortalezas puede el equipo del proyecto
Página 252
entregar el producto que el usuario necesita. Los auditores de TI pueden participar revisando los requisitos y
verificar la comprensión y aprobación del usuario. Un buen punto de control para los auditores de TI es asegurarse de que en
En la fase de Análisis y Requisitos del Sistema, se incluye la definición de los requisitos de seguridad. La cosa
El auditor debe identificar y documentar los requisitos de seguridad en las primeras etapas del ciclo de vida del desarrollo.
y asegúrese de que los artefactos de desarrollo posteriores se evalúen para verificar el cumplimiento
requisitos. Cuando los requisitos de seguridad no están definidos, la seguridad del sistema resultante
no se puede evaluar de manera efectiva y el costo de modernizar el sistema más adelante en su ciclo de vida puede ser
extremadamente costoso.
Tarea de auditor: diseño del sistema
El auditor de TI puede revisar el trabajo de diseño para detectar posibles exposiciones o controles olvidados, según
así como el cumplimiento de los estándares, políticas y procedimientos de la empresa. Estándares, políticas y
Los procedimientos deben documentarse como parte de la metodología SDLC y definirse antes de la
inicio del proyecto. Si se identifican exposiciones, controles faltantes y / o falta de cumplimiento,
el auditor de TI debe recomendar los controles o procedimientos adecuados.
Como se vio anteriormente, una metodología o técnica que atrae a los usuarios y miembros del equipo del proyecto
juntos para un taller intensivo en el que crean una propuesta de sistema en un diseño de detalle es
JAD. Por lo general, un facilitador de JAD capacitado, que tiene cierto reclamo de neutralidad, lleva al grupo
discusiones o sesiones formateadas del sistema. El auditor de TI puede ser un participante activo en
este proceso. El resultado de la sesión JAD es una vista de usuario del sistema para un mayor desarrollo.
Este es un escenario excelente para la discusión de las ventajas y la rentabilidad de los controles.
Además, se comprime el tiempo de análisis, se resuelven las discrepancias, se reducen los errores de especificación y
comunicaciones muy mejoradas. Los auditores de TI pueden revisar los entregables y recomendar aplicaciones
controles de Los controles de la aplicación se describen con más detalle en un capítulo posterior.
Tarea de auditor: desarrollo

El auditor de TI puede revisar los programas del nuevo sistema para verificar el cumplimiento de la programación y
estándares de codificación. Estos estándares ayudan a garantizar que el código esté bien estructurado, rastree las dependenci
cies y facilita el mantenimiento. El auditor de TI puede revisar una muestra de programas para verificar que
se están siguiendo los estándares y que los programas se ajustan al diseño de los sistemas. Adicionalmente,
Los programas pueden ser revisados para posibles exposiciones de control y para la colocación de controles adecuados.
por diseño. Si se determina que se necesitan controles, el auditor de TI debe hacer recomendaciones
ciones, siguiendo los mismos criterios que se utilizaron durante la fase de Diseño del Sistema. Durante esto
Sin embargo, en la fase de desarrollo, los factores de costo y tiempo deben considerarse cuidadosamente porque el costo
de cambiar programas para incluir controles aumenta a medida que avanza el proyecto.
Tarea de auditor: prueba

El auditor de TI puede ser llamado para asegurar a la gerencia que tanto los desarrolladores como los usuarios
probado minuciosamente el sistema para asegurarse de que:
◾ posee los controles integrados necesarios para proporcionar una garantía razonable de funcionamiento adecuado;
◾ proporciona la capacidad de rastrear eventos a través de los sistemas y, por lo tanto, apoya la revisión de auditoría
del sistema en funcionamiento; y
◾ satisface las necesidades del usuario y la gestión.
Página 253
Si el nivel de prueba no cumple con los estándares, el auditor de TI debe notificar al equipo de desarrollo
o la gerencia, que luego debería tomar medidas correctivas.
Tarea de auditor: implementación

La implementación del sistema es un punto clave de revisión de la auditoría de TI porque la implementación a menudo es do
Los controles críticos pueden sobrescribirse o desactivarse para que el sistema funcione y cumpla
necesidades y requisitos organizativos. El auditor de TI debe revisar los materiales de implementación
relacionados con los procedimientos de estrategia, comunicación, capacitación, documentación y conversión, entre
otros. También se debe revisar la preparación para la producción, lo que puede incluir la evaluación de la preparación
del sistema en relación con los resultados de las pruebas, la preparación del programa de apoyo a la producción
usuarios, operaciones informáticas y usuarios en términos de formación, y la preparación de la mesa de ayuda con
personal capacitado y un proceso de seguimiento de problemas.
Una vez que el sistema se implementa en producción, el auditor de TI puede encuestar a los usuarios para: evaluar
su eficacia desde la perspectiva del flujo de trabajo; revisar los procedimientos de detección y corrección de errores
para confirmar que funcionan según lo previsto; y realizar pruebas de datos para confirmar la integridad de
procesamiento de transacciones y seguimiento de auditoría.
Tarea de auditor: operaciones y mantenimiento

En esta fase, el auditor de TI evalúa los procesos y procedimientos posteriores a la implementación. Por ejemplo,
Las modificaciones del código y los procedimientos de prueba deben evaluarse para determinar si el
se están siguiendo los estándares, políticas y / o procedimientos de la organización. El auditor de TI también
procedimientos de conductos para asegurar que los sistemas estén bien mantenidos; es decir, los programadores corrigen pro
realizar las mejoras necesarias de manera oportuna y adecuada. Al mantener la aplicación
sistemas, el auditor de TI debe asegurarse de que la corrección de problemas y / o la instalación de mejoras
ambos se trabajan en un entorno de prueba independiente y, con resultados satisfactorios, se promueven a
el entorno de producción. Hay otras métricas comunes que deben ser revisadas por el departamento de TI.
auditor para evaluar la efectividad y eficiencia del proceso de mantenimiento:
◾ La relación entre el costo de mantenimiento real por aplicación y el promedio de todas las aplicaciones.
◾ Tiempo promedio solicitado para entregar solicitudes de cambio.
◾ La cantidad de solicitudes de cambio para la aplicación que estaban relacionadas con errores, errores críticos,
y nuevas especificaciones funcionales.
◾ El número de problemas de producción por aplicación y por cambios de mantenimiento respectivos.
◾ El número de divergencias con respecto a los procedimientos estándar, como solicitudes no documentadas,
diseño no aprobado y pruebas de reducción.
◾ El número de módulos devueltos al desarrollo debido a errores descubiertos en la aceptación
pruebas.
◾ Tiempo transcurrido para analizar y solucionar problemas.
◾ Porcentaje de software de aplicación efectivamente documentado para mantenimiento.
Otro procedimiento relevante realizado durante esta fase es la revisión y evaluación de todos los
sistema, usuario o documentación operativa. Dicha documentación debe evaluarse para verificar que esté
ness y exactitud. La documentación debe ser práctica y fácilmente comprensible para todos los tipos de usuarios.
(por ejemplo, usuarios finales, programadores, alta dirección, etc.). Diagramas de flujo de información, muestras
de posibles documentos / pantallas de entrada e informes de salida son algunos ejemplos de información que
mejorar la comprensión del sistema por parte del usuario y, por lo tanto, debe documentarse.
Página 254
La figura 8.11 ilustra una plantilla de una lista de verificación de auditoría estándar que se puede utilizar como punto de
punto al evaluar las fases SDLC para un proyecto. La lista de verificación se basa en la norma ISO /
IEC 12207: 2013- Procesos del ciclo de vida del software de ingeniería de sistemas y software , que proporciona
orientación para definir, desarrollar, controlar, mejorar y mantener el sistema / software
Procesos del ciclo de vida. El estándar también se puede adaptar según el sistema / software particular
proyecto de cerámica.
Figura 8.11 Lista de verificación de auditoría de SDLC de muestra
Muestra de lista de verificación de auditoría de SDLC: desarrollo e implementación de una aplicación financiera
Sistema
Sí No,
Tarea N/A Comentarios
Fase 1: planificación
1. Establecer y preparar un plan de proyecto general con tareas definidas

y entregables.
2. El plan incluye el alcance del trabajo (p. Ej., Período, nombre del nuevo
sistema, horario, restricciones, etc.), los recursos necesarios y
plazos requeridos.
3. El plan describe el alcance de las responsabilidades de todos los involucrados.

personal (por ejemplo, gerencia, auditoría interna, usuarios finales, calidad
aseguramiento (QA), etc.)
4. El plan identifica los requisitos del equipo, como el hardware

configuración necesaria para utilizar el nuevo sistema (por ejemplo, procesamiento
velocidad, espacio de almacenamiento, medios de transmisión, etc.).
5. El plan incluye análisis financieros detallados, incluidos los costos de

desarrollar y operar el nuevo sistema y el retorno de
inversión.
6. El plan se revisa y aprueba en los niveles apropiados.
Fase 2: Análisis y requisitos del sistema
1. El análisis incluye un estudio para determinar si el nuevo sistema

debe ser desarrollado o comprado.
2. El análisis incluye un estudio del sistema actual para identificar

procesos y procedimientos existentes que pueden continuar en el
nuevo sistema.
3. Los procedimientos para realizar un análisis de necesidades son los adecuados

evaluado y conforme a los estándares, políticas,
y / o procedimientos.
4. Expectativas de los usuarios finales y analistas de sistemas para el nuevo o

El sistema modificado se traduce claramente en requisitos.
( Continuacion )
Página 255
Figura 8.11 ( continuación ) Muestra de lista de verificación de auditoría de SDLC
Sistema
Sí No,
5. Los requisitos del nuevo software / sistema se definen en términos

que se puede medir.
6. Los requisitos son cuantificables, medibles, relevantes y
detallado.
Fase 3: Diseño del sistema
1. El diseño describe el flujo del sistema propuesto y otros

información sobre cómo funcionará el nuevo sistema (es decir, conceptual
diseño).
2. Las especificaciones, características y operaciones del diseño del sistema cumplen con
requisitos previamente definidos.
3. Las especificaciones de diseño del sistema están aprobadas y cumplen con las
los estándares, políticas y / o procedimientos de la organización.
4. El analista de sistemas define y documenta todas las interfaces del sistema,

informes, diseños de pantalla y lógica de programa específica necesaria para
construir el sistema de acuerdo con los requisitos.
5. El analista de sistemas y los usuarios finales revisan y se aseguran de que

las necesidades comerciales específicas se han traducido en la
requisitos para el nuevo sistema.
6. Detalles técnicos del sistema propuesto (por ejemplo, hardware y / o

software necesario, capacidades de red, procedimientos para el
sistema para lograr sus objetivos, etc.) se han discutido
con las partes interesadas adecuadas.
7. El diseño del sistema describe los controles para los puntos de entrada,
procesamiento y diseño / salida de pantalla.
8. El diseño del sistema incorpora pistas de auditoría y

controles programados.
Fase 4: Desarrollo
1. Obtenga y revise el código fuente / programa para el nuevo o

sistema o aplicación modificados.
2. Determine si el código fuente / programa cumple con los

los estándares de programación de la organización, políticas y / o
procedimientos.
3. Se prueba la sintaxis y la lógica del código fuente / programa

fluir.
( Continuacion )
Página 256
Sistema
Sí No,
4. Todas las rutas lógicas dentro del código fuente / programa se ejercitan para
Asegúrese de que las rutinas de error funcionen y el programa finalice
procesando normalmente.
5. Se configuran e incorporan controles de acceso de seguridad lógica

dentro del código fuente / programa.
6. Los controles de seguridad configurados están diseñados para abordar

requisitos relacionados con la confidencialidad, integridad y
disponibilidad de información.
7. Los controles de seguridad configurados están diseñados para abordar

procesos de autorización y autenticación, así como negocios
requisitos de acceso y seguimiento.
8. El código fuente / programa se valida a través de una unidad individual.

pruebas (las pruebas exhaustivas del sistema se evalúan en la fase de pruebas ).
La fase de desarrollo es final una vez que el código fuente / programa es
validado.
Fase 5: Prueba
1. Se prepara un plan para las pruebas del sistema que se ajusta a

2. El plan de prueba define: eventos y escenarios de prueba individuales;

roles y responsabilidades de los participantes de la prueba; prueba
ambientes; criterios de aceptación; pruebas de logística; problema
informes y seguimiento; entregables de prueba; y personal
responsable de la revisión y aprobación de las pruebas y los resultados de las pruebas.
3. Las pruebas se basan en las metodologías de prueba existentes establecidas por

la organización.
4. Las pruebas incluyen datos de prueba (reales o generados) que son representativos
de los escenarios empresariales relevantes.
5. Los escenarios de prueba, los datos asociados y los resultados esperados son
documentado para cada condición de prueba.
6. Las pruebas realizadas están documentadas para evitar pruebas duplicadas.

esfuerzos.
7. Los usuarios finales realizan las pruebas; ni desarrolladores ni programadores.
8. Las pruebas se realizan en entornos separados / de desarrollo; no

en entornos de producción.
( Continuacion )
Página 257
Sistema
Sí No,
9. Los resultados de las pruebas se firman y aprueban, según corresponda, para respaldar
que se realizaron las pruebas adecuadas y garantizar que dichas pruebas
los resultados son consistentes con los requisitos.
10. Los sistemas con resultados de prueba no satisfactorios no se implementan en el

11. Tras los resultados satisfactorios de las pruebas, el personal de gestión firma
aprobar la promoción de sistemas nuevos o modificados en producción
Ambientes.
12. El sistema es evaluado por un profesional de control de calidad para verificar que funciona.
según lo previsto y que cumpla con todas las especificaciones de diseño.
13. Procedimientos de prueba documentados, datos de prueba y productos resultantes

se revisan para determinar si son completos y siguen las
14. Los resultados de las pruebas del sistema validan que el sistema funciona como
esperado y que todos los errores, fallas, fallas o fallas identificadas
han sido corregidos y no impiden que el sistema funcione
efectivamente.
Fase 6: Implementación
1. Se documenta y se implementa un plan de implementación para guiar

el equipo de implementación y los usuarios en todo el
proceso de implementación.
2. El plan de implementación cubre el cronograma de implementación,

procedimientos de conversión (si los hay), recursos requeridos, roles y
responsabilidades de los miembros del equipo, medios de comunicación,
procedimientos de gestión de problemas y planes de formación para el
3. El plan de implementación incluye la fecha y hora en que

Se instalará un nuevo sistema o cambios a uno existente.
4. La documentación relacionada con la implementación del sistema se ha

publicado y comunicado a los usuarios.
5. El sistema fue probado con éxito antes de su implementación en el

entorno de producción coherente con los estándares de la organización,
Policias y procedimientos.
6. La documentación relacionada con la implementación proporciona a los programadores

con suficiente información para comprender cómo funciona el sistema,
y asegurar un análisis eficaz y eficiente de los cambios y
solución de problemas.
( Continuacion )
Página 258
Sistema
Sí No,
7. La documentación relacionada con la implementación se actualiza a medida que

se modifica el sistema.
8. Se han incorporado procedimientos de formación en el sistema.

9. Se proporciona soporte (por ejemplo, a través de un servicio de asistencia técnica, etc.) a los usuarios que siguen
implementación.
10. Determine si los estándares, políticas y / o normas de la organización

se siguen los procedimientos y si la documentación de apoyo
el cumplimiento de las normas está disponible.
Fase 7: Operaciones y mantenimiento
1. Revisar y evaluar los procedimientos para realizar post-

revisiones de implementación.
2. Revisar las modificaciones del sistema, los procedimientos de prueba y los

documentación para determinar si los estándares de la organización,
se han seguido políticas y / o procedimientos.
3. Se establece un sistema de informes para que los usuarios se comuniquen

problemas o mejoras necesarias.
4. Existen procedimientos para que los programadores corrijan los problemas.

con el nuevo sistema o realizar las mejoras necesarias.
5. La corrección de problemas o mejoras al nuevo sistema son

trabajó en un entorno de prueba / separado, y con éxito
resultados, promovidos al entorno productivo.
Comunicación
La primera área a comunicar es el alcance de participación del auditor de TI en el proyecto de SD&I. Es
muy importante asegurarse de que las expectativas de los equipos de gestión y desarrollo de TI
el papel del auditor se entiende y se comunica a todos los participantes. Para influir en el esfuerzo de SD&I,
el auditor de TI debe desarrollar una línea abierta de comunicación tanto con la administración como con los usuarios. Si
no existe una buena relación entre estos grupos, la información podría ser retenida
Auditor de TI. Este tipo de situación podría impedir que el auditor de TI haga el mejor trabajo posible.
Además, el auditor de TI debe desarrollar una buena relación de trabajo con analistas y programas
mers. Aunque el auditor de TI debe cultivar buenas relaciones de trabajo con todos los grupos con
responsabilidades de diseño, el auditor de TI debe permanecer independiente.
A lo largo del proyecto SD&I, el auditor de TI hará recomendaciones de control como resultado:
a partir de los hallazgos identificados. Dependiendo de la cultura de la organización, estas recomendaciones
Página 259
Es posible que deba manejarse informalmente mediante la revisión de diseños con el equipo del proyecto o formalmente por
presentándolos al comité directivo. En cualquier caso, el auditor de TI siempre debe
Considere el valor de la recomendación de control frente al costo de implementar el control.
Las recomendaciones deben ser específicas. Deben identificar el problema y no los síntomas.
tom y permitir que se implementen y prueben los controles adecuados. Hallazgos, riesgos como
resultado de esos hallazgos, y las recomendaciones de auditoría generalmente se documentan en una carta formal
(es decir,
Carta carta dedegestión).
de gestión Consulte
una auditoría el Anexo 3.9 en el Capítulo 3 para ver un ejemplo del formato de un
de TI.
Al recibir la carta de gestión, la dirección de TI y el personal afectado deben revisar la
documento. Los problemas y asuntos que aún no se hayan completado deben manejarse y seguirse. Dentro
un tiempo relativamente corto, el hecho de que se hayan corregido todas las discrepancias debe transmitirse a
el personal de auditoría de manera formal. Estas acciones se anotan en los archivos de auditoría y dicha cooperación
se refleja favorablemente en futuras auditorías.
Sin embargo, las recomendaciones a menudo pueden rechazarse debido a un factor de tiempo y costo. Gerentes
a veces puede sentir que la implementación de las recomendaciones de un auditor retrasará su cronograma.
El auditor de TI debe convencer a la gerencia del valor de las recomendaciones y que si
no se implementan, se gastará más tiempo y dinero a largo plazo. Informar a la gerencia
del costo de implementar un control ahora, en lugar de apagar el sistema más tarde (dejando
exposiciones potenciales abiertas), ayudará a convencer a la dirección de la necesidad de tomar medidas adecuadas y
acción inmediata.
Conclusión
El desarrollo de nuevos sistemas puede resultar una tarea costosa y que requiere mucho tiempo. Un bien controlado
entorno con una estrategia general, estándares, políticas y procedimientos establecidos ayuda a garantizar
el éxito del desarrollo del sistema y los esfuerzos de implementación. Hay muchos procesos que
deben seguirse para garantizar el éxito general de un sistema. Estos procesos o fases son
proporcionado por un SDLC. El SDLC proporciona un marco para el desarrollo eficaz de aplicaciones
sistemas de Describe específicamente un proceso estándar para planificar, analizar, diseñar,
crear, probar, implementar y mantener sistemas de información (es decir, nuevo desarrollo o
sistema modificado).
La organización debe evaluar constantemente los riesgos relacionados con las fases de SDLC. Estas
Los riesgos son importantes tanto para la organización como para el auditor de TI y deben impulsar la identificación
tificación (e implementación) de controles que puedan mitigarlos. Debido al costo de implementar
controles de seguridad después de que un sistema ya ha sido implementado en producción, los controles deben ser
definido antes de que se construya un sistema.
Hay varios enfoques aplicables al desarrollo de sistemas. Aunque cada enfoque es
único, todos tienen pasos similares que deben completarse. Por ejemplo, cada enfoque
tienen que definir los requisitos del usuario, diseñar programas para cumplir con esos requisitos, verificar que
Los gramos funcionan según lo previsto e implementan el sistema. Los auditores de TI deben comprender las diferentes
enfoques, los riesgos asociados con el enfoque particular, y ayudar a garantizar que todos los
Los procedimientos y controles sary están incluidos en el proceso de desarrollo.
Existen muchas oportunidades para la participación del auditor en el proceso de SD&I. Auditores de TI
puede ayudar a las organizaciones revisando el entorno de SD&I; evaluar estándares para SD&I;
monitorear el progreso del proyecto; evaluar las fases del proceso de SD&I; revisar sistemas críticos
para entrada, procesamiento y salida; verificar que el nuevo sistema proporciona una auditoría adecuada
Página 260
sendero; y asegurando que se identifiquen los riesgos y se consideren los controles adecuados durante la
Las auditorías de SD&I, por ejemplo, se realizan para evaluar los controles administrativos sobre el
autorización, desarrollo e implementación de nuevos sistemas (es decir, aplicaciones), y para revisar
el diseño de los controles / pistas de auditoría del sistema propuesto. El alcance de una auditoría de SD&I incluye
una evaluación del enfoque o metodología general de SDLC. La auditoría también se centra en la evaluación
ación de la calidad de los entregables de cada fase de desarrollo del sistema (por ejemplo, evaluación de la
controla el diseño y las pistas de auditoría, el plan y los resultados de las pruebas del sistema, la formación del usuario, la do
etc.). Las recomendaciones de las auditorías de SD&I pueden incluir mejoras en los requisitos del usuario,
controles de la aplicación, o la necesidad de documentar los planes de prueba y los resultados esperados de la prueba.
1. ¿Cómo proporciona un ciclo de vida de desarrollo de sistemas (SDLC) un entorno propicio
al desarrollo exitoso de sistemas?
2. Describa el propósito de los datos de prueba.
3. Explique a qué procedimientos de conversión se refieren como parte de la implementación de un nuevo sistema.
4. ¿Por qué deben abordarse los planes de recuperación ante desastres durante una implementación en lugar de
¿después?
5. ¿Por qué una función de mesa de ayuda es fundamental para el desarrollo del sistema? Discutir su interrelación
con el sistema de informes y gestión de problemas.
6. ¿Por qué es necesario que los programadores tengan buena documentación como parte de las operaciones?
y fase de mantenimiento del SDLC?
7. Discutir cómo el auditor de TI puede beneficiar el desarrollo e implementación del sistema de una organización.
proceso de mentación.
8. Diferenciar entre los dos roles que los auditores de TI pueden asumir en un proyecto de SD&I.
9. ¿Qué metodología o técnica se utiliza para reunir a los usuarios y a los miembros del equipo del proyecto?
para crear un diseño de detalle?
10. A lo largo del proyecto de implementación y desarrollo del sistema, el auditor de TI hará
recomendaciones de control a la gerencia resultantes de los hallazgos identificados Explicar por qué
las recomendaciones de los auditores de TI a menudo pueden rechazarse.
Ejercicios
1. Resumir las fases comunes en el ciclo de vida de desarrollo de sistemas tradicionales (SDLC)
Acercarse.
2. Una empresa está desarrollando un nuevo sistema. Como auditor de TI interno, recomienda que
la planificación del desarrollo del nuevo sistema debe ser coherente con el marco SDLC.
El personal de TI ha identificado las siguientes como actividades principales que deben completarse dentro del
próximo desarrollo del sistema.
- Asegúrese de que la mesa de ayuda esté en su lugar para brindar soporte
- Integración de controles de acceso de seguridad dentro del código
- Corregir problemas e implementar mejoras
Página 261
- Procedimientos de conversión de datos

- Discusión de detalles técnicos y especificaciones.
- Definición de requisitos funcionales
- Realizar pruebas de varios escenarios.
- Planificación de la implementación
- Documentar los procedimientos del usuario, impartir formación
- Revisión del sistema actual
Organice estas 10 actividades en la secuencia en la que crea que deberían realizarse. En
Además, el personal de TI no está muy seguro de qué proceso seguir cuando se convierte
ing archivos de datos del sistema antiguo al nuevo. Describe los cuatro métodos de conversión de datos.
disponible que puede ser aplicable en este caso
3. Prepare una tabla del programa de auditoría de una página y dos columnas que enumere todos los riesgos que se le ocu
son importantes para cualquier organización al implementar las fases de SDLC. Junto a los riesgos,
Enumere los controles y procedimientos de TI relevantes que deberían estar en su lugar para mitigar los riesgos enum
Asegúrese de documentar al menos un control de TI por cada riesgo enumerado.
4. Enumere las ventajas y desventajas de cada uno de los enfoques de desarrollo de sistemas analizados.
en el capítulo.
5. Diferenciar entre los distintos eventos de prueba del sistema. Describe qué aspectos del sistema son
cubierto durante cada evento.
6. El capítulo destaca nueve responsabilidades clave para los auditores cuando participan en un proyecto de SD&I
ect. Involucrarse en puntos estratégicos durante dicho proceso, los auditores pueden asegurar que
el sistema que se está desarrollando e implementando está bien controlado y auditable. Lista y
Explique con sus propias palabras el significado de cada una de estas nueve responsabilidades.
CASO: CUMPLIMIENTO DE LOS ESTÁNDARES Y CONTROLES SDLC
INSTRUCCIONES: Para obtener una ventaja competitiva y mantenerse al día con el negocio
crecimiento, la empresa para la que trabaja decidió desarrollar e implementar un nuevo sistema.
También se espera que el nuevo sistema de última generación aumente la productividad y automatice la
operaciones de alquiler, entre otras. Es un momento muy emocionante para su empresa. Tu eres el
Líder a cargo de este proyecto y acaba de terminar una reunión de planificación con la alta gerencia.
ment. En la reunión, tanto el CIO como el CEO solicitaron que para acelerar la
proceso de implementación, usted y su equipo retrasan el cumplimiento de estándares SDLC comunes
así como agregar los controles necesarios al nuevo sistema hasta después de que se implemente en el
entorno de producción. Esta solicitud te tomó por sorpresa y te hizo sentir incómodo.
poder. No cree que deba cumplir con la solicitud.
TAREA: Documentar, en formato de memorando, las razones por las que no debe cumplir con la
Solicitud de CIO y CEO. Debe respaldar su respuesta (razones) con literatura de TI y /
o cualquier otra fuente externa válida. Incluya ejemplos, según corresponda, para evidenciar su caso
punto. Envíe un archivo de Word con una portada, respuestas a las tareas anteriores y una referencia.
sección al final. El archivo enviado debe tener entre 8 y 10 páginas (doble línea
espaciado), incluida la portada y las referencias. Esté preparado para presentar su trabajo a la clase.
Página 262
CASO: PARTICIPACIÓN DE LA AUDITORÍA DE TI EN EL SISTEMA

DESARROLLO E IMPLEMENTACIÓN
INSTRUCCIONES: El presidente de la empresa acaba de preguntarle, Auditoría Interna de TI

Manager, para participar en el próximo desarrollo e implementación de una nueva información
sistema de mación. Se espera que el nuevo sistema aumente la productividad al automatizar la corriente
operaciones. El nuevo sistema se implementará en los próximos 6 meses. El presidente
También solicitó que el sistema implementado esté listo para (y pase exitosamente) la próxima TI
auditoría externa.
TAREA: Describa los procedimientos de auditoría que realizaría para completar la tarea asignada.
Incluya, como mínimo, una descripción de lo siguiente:
◾ Plan de auditoría, incluido el propósito y el alcance de la participación; rol y responsabilidades,

etc.
◾ Procedimientos de auditoría que se realizarán en cada fase del SDLC, incluida la documentación
fuente de información necesaria; métodos para documentar dicha información; métodos
de verificar la información recopilada, etc.
◾ Comunicación de la participación de la auditoría, los resultados y las recomendaciones a la gerencia.
resultante de los procedimientos de auditoría realizados.
Envíe un archivo de Word con una portada, respuestas a las tareas anteriores y una sección de referencia en
el fin. El archivo enviado debe tener al menos ocho páginas (interlineado doble), incluyendo
portada y referencias. Esté preparado para presentar su trabajo a la clase.
Otras lecturas
1. Desarrollo de software adaptativo. La guía definitiva para el SDLC . http://ultimatesdlc.com/adaptive-
software-development / (consultado el 30 de junio de 2017).
2. TechTarget. Pruebas de software automatizadas. http://searchsoftwarequality.techtarget.com/definition/
automatic-software-testing (consultado el 1 de julio de 2017).
3. Fundamentos de las pruebas de software. Prueba de caja negra. http://softwaretestingfundamentals.com/black-
box-testing / (consultado el 1 de julio de 2017).
5. Hettigei, N. (2005). El papel del auditor en proyectos de desarrollo de TI, auditoría de sistemas de información y
Asociación de control. Inf. Syst. Estafa. J. , 4, 44.
6. ISO / IEC 12207: 2013- Procesos del ciclo de vida del software de ingeniería de sistemas y software. Internacional
Organización de Normalización. www.iso.org/standard/43447.html (consultado el 6 de julio de 2017).
7. Fundación de Auditoría y Control de Sistemas de Información , Directrices de Aseguramiento y Auditoría de SI , ISACA,
Septiembre de 2014.
8. JAD (Desarrollo de aplicaciones conjuntas). http://searchsoftwarequality.techtarget.com/definition/JAD
9. Jones, DC, Kalmi, P. y Kauhanen, A. (2011). Efectos de la empresa y los empleados de una información empresarial
sistema de mación: Evidencia microeconométrica. Revista Internacional de Economía de la Producción , 130 (2),
159-168.
10. Kanban. Metodologías PM . www.successfulprojects.com/PM-Topics/Introduction-to-Project-
Management / PM-Methodologies (consultado el 29 de junio de 2017).
Página 263
11. Mallach, Efrem G. (2011). Estrategias de conversión de sistemas de información: una visión unificada. En la gestión
Adaptabilidad, intervención y personas en los sistemas de información empresarial , ed. Madjid Tavana, 91-105
(consultado el 5 de julio de 2017). doi: 10.4018 / 978-1-60960-529-2.ch005.
12. Merhout, J. y Kovach, M. (2017). Prácticas de gobernanza sobre proyectos de desarrollo de sistemas ágiles:
Una agenda de investigación. Actas de la Duodécima Asociación Anual del Medio Oeste de Sistemas de Información
Conferencia (MWAIS 2017), Springfield, Illinois, 18-19 de mayo de 2017.
13. OWASP. Prácticas de codificación
Secure_Coding_Practices seguras: guía de referencia
_-_ Quick_Reference_Guide rápida.elwww.owasp.org/index.php/OWASP_
(consultado 28 de junio de 2017).
14. Protiviti. (2016). Desde la nube, móvil, social, IoT y análisis hasta la digitalización y la ciberseguridad:
Prioridades de evaluación comparativa para los líderes tecnológicos de hoy . www.knowledgeleader.com/KnowledgeLeader/
Content.nsf / Web + Content / SRFromCloudMobileSocialIoTandAnalytics! OpenDocument (consultado
28 de junio de 2017).
15. Rama, J., Corkindaleb, D. y Wu, M. (2013). Factores críticos de éxito de la implementación (CSF)
para ERP: ¿Contribuyen al éxito de la implementación y al desempeño posterior a la implementación?
Revista Internacional de Economía de la Producción , 144 (1), 157-174.
16. Red de desarrolladores de Microsoft. Pruebas de regresión. https://msdn.microsoft.com/en-us/library/
aa292167 (v = vs.71) .aspx (consultado el 1 de julio de 2017).
18. Schiesser, R. Garantizar la preparación de la producción antes de la implementación . Prentice Hall PTR, Nueva York,
www.informit.com/isapi/product_id·%7B0CF23CBC-CDCC-4B50-A00E-17CBE595AA31%7D/
content / index.asp (consultado el 1 de agosto de 2003).
19. Scrum. Metodologías PM . www.successfulprojects.com/PM-Topics/Introduction-to-Project-
Management / PM-Methodologies (consultado el 29 de junio de 2017).
20. Política y seguridad de la información de Berkeley. Pautas de práctica de codificación segura. https: //security.berkeley.
edu / secure-coding-practice-Guidelines (consultado el 1 de julio de 2017).
21. Estándares de codificación SEI CERT. (2017). Instituto de Ingeniería de Software. www.securecoding.cert.org/
confluencia / display / seccode / SEI + CERT + Codificación + Estándares
23. TechTarget. Pruebas de rendimiento de software. http://searchsoftwarequality.techtarget.com/definition/
performance-testing (consultado el 1 de julio de 2017).
24. Arquitectos innovadores. Las siete fases del ciclo de vida del desarrollo del sistema. www.
innovationarchitects.com/KnowledgeCenter/basic-IT-systems/system-development-life-cycle.
aspx (consultado el 27 de junio de 2017).
25. Waters, K. (2010). 7 principios clave del desarrollo de software ajustado . Desarrollo Lean. www.101ways.
com / 7-principios-clave-del-desarrollo-de-software-lean-2 /
26. Alianza ágil. ¿Qué es el desarrollo de software ágil? www.agilealliance.org/agile101/ (consultado en junio
28 de 2017).
27. Fundamentos de las pruebas de software. Prueba de caja blanca. http://softwaretestingfundamentals.com/white-
box-testing / (consultado el 1 de julio de 2017).
28. US-CERT, las 10 mejores prácticas de codificación , Instituto de Ingeniería de Software, Universidad Carnegie Mellon, www.
securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices marzo de 2011.
Página 265
264
AUDITANDO
MEDIO AMBIENTE III
Página 267
266
Capítulo 9
Sistemas de aplicación:
Riesgos y controles
1. Analice los riesgos comunes asociados con los sistemas de aplicación.
2. Analice los riesgos comunes asociados con los sistemas de aplicaciones de desarrollo del usuario final.
3. Discutir los riesgos de los sistemas que intercambian información comercial y describir los estándares comunes.
para sus evaluaciones de auditoría.
4. Describa las aplicaciones web, incluidas las mejores prácticas de codificación segura y los riesgos comunes.
5. Explique los controles de la aplicación y cómo se utilizan para salvaguardar la entrada, el procesamiento y
salida de información.
6. Analice la participación del auditor de TI en un examen de los sistemas de aplicación.
Los sistemas de aplicación proporcionan funciones automatizadas para respaldar eficazmente el proceso empresarial.
Las aplicaciones también presentan riesgos para las organizaciones en forma de aumento de costos, pérdida de datos
integridad, debilidades en la confidencialidad, falta de disponibilidad y bajo desempeño, entre otros.
Además, una vez implementadas, las aplicaciones pueden modificarse periódicamente para corregir errores o
simplemente implemente actualizaciones y mejoras (mantenimiento). Dicho mantenimiento deberá ser
coherente con las estrategias comerciales o de TI; de lo contrario, puede causar problemas de rendimiento e ineficacia
uso de recursos.
Este capítulo analiza los riesgos comunes a varios tipos de sistemas de aplicación y proporciona
ejemplos de tales riesgos potenciales. También toca los controles de aplicación relevantes que se pueden
implementado por las organizaciones con el fin de mitigar los riesgos discutidos. Por último, la participación del
Se discute el auditor de TI al examinar las aplicaciones.
Riesgos del sistema de aplicación

Los sistemas de aplicación incluyen datos concentrados en un formato al que se puede acceder fácilmente. Tal con-
El centrado de datos aumenta los riesgos al confiar más en un solo dato o en un
241
Página 268
archivo de computadora único o en una tabla de base de datos. Si los datos ingresados son erróneos, el impacto del error
sería significativo ya que las aplicaciones se basan en ese tipo de datos. Del mismo modo, cuanto mayor sea el número
de aplicaciones que utilizan los datos concentrados, mayor es el impacto cuando esos datos se convierten
no disponible debido a problemas de hardware o software. Un buen ejemplo para promover la discusión de
Los sistemas de aplicación son un sistema de planificación de recursos empresariales (ERP).
Los sistemas ERP proporcionan funcionalidad empresarial estándar en un sistema de entorno de TI integrado
(por ejemplo, adquisiciones, inventario, contabilidad y recursos humanos). Los sistemas ERP permiten múltiples
funciones para acceder a una base de datos común, lo que reduce los costos de almacenamiento y aumenta la coherencia y
precisión de los datos de una sola fuente. De hecho, tener una sola base de datos mejora la calidad y
actualidad de la información financiera. Sin embargo, los errores de procesamiento pueden afectar rápidamente a múltiples f
ciones ya que la información se comparte pero se obtiene de la misma base de datos. Según junio de 2016
edición de Apps Run the World, una empresa de investigación de mercado de tecnología dedicada a la aplicación
espacio, el mercado mundial de aplicaciones ERP alcanzará los $ 84.1 mil millones para 2020 en comparación con
$ 82,1 mil millones en 2015. Algunos de los principales proveedores de ERP en la actualidad incluyen SAP, FIS Global, Ora
Fiserv, Intuit, Inc., Cerner Corporation, Microsoft, Ericsson, Infor y McKesson.
A pesar de las muchas ventajas de los sistemas ERP, no están exentos de riesgos. Los sistemas ERP no son
muy diferente a los sistemas de aplicación comprados o empaquetados y, por lo tanto, pueden requerir más
sivas modificaciones a los procesos comerciales nuevos o existentes. Modificaciones de ERP (es decir, versiones de softwar
requieren una programación considerable para actualizar todo el código específico de la organización. Porque paquete
Los sistemas antiguos son genéricos por naturaleza, las organizaciones pueden necesitar modificar sus operaciones comercia
coincidir con el método de procesamiento del proveedor, por ejemplo. Los cambios en las operaciones comerciales pueden n
bien en la cultura de la organización u otros procesos, y también puede ser costoso debido a la capacitación. En
Además, es posible que se requiera cierta integración para la funcionalidad que no es parte del ERP, pero
proporciona información integral a las funciones del ERP. Además, como los sistemas ERP son ofrecidos por un único
proveedor, los riesgos asociados con tener un solo proveedor se aplican (por ejemplo, dependiendo de un solo proveedor par
mantenimiento y soporte, requisitos específicos de hardware o software, etc.).
Otro riesgo con los sistemas ERP es la naturaleza especializada de los recursos necesarios para personalizar
e implementar. En la mayoría de las organizaciones, estos recursos especializados deben obtenerse de
firmas consultoras cotizadas. Para disminuir la dependencia de consultores de alto precio, las organizaciones
necesitan invertir en la formación de su propio personal para que asuman la responsabilidad de mantener el ERP
sistema. Como estos recursos tienen una gran demanda, el desafío es mantenerlos una vez que
están completamente capacitados.
Los sistemas ERP pueden ser bastante complejos con la base de datos subyacente, los módulos de aplicación y
interfaces con aplicaciones heredadas y de terceros. La complejidad de los sistemas ERP puede en realidad
cuestan más que los entornos de aplicaciones múltiples que se pretendía reemplazar.
Los sistemas de aplicación, como los sistemas ERP, están expuestos con frecuencia a muchos tipos de riesgos. Adiciona
Los riesgos comunes asociados con los sistemas de aplicación incluyen:
◾ Seguridad de la información débil

◾ Acceso no autorizado a programas o datos
◾ Acceso remoto no autorizado
◾ Información inexacta
◾ Entrada de datos errónea o falsificada
◾ Procesamiento incompleto, duplicado e inoportuno
◾ Fallo del sistema de comunicaciones
◾ Salida inexacta o incompleta
◾ Documentación insuficiente
Página 269
Sistemas de aplicación: riesgos y controles ◾ 243
Seguridad de la información débil

La seguridad de la información debe ser una preocupación de TI, usuarios y administración. Sin embargo, no ha
ha sido una prioridad principal constante para muchas organizaciones. Encuestas e informes anteriores han demostrado que
Las organizaciones están más preocupadas por los presupuestos y la escasez de personal que por la seguridad de la informac
Los encuestados siguen identificando obstáculos para reducir la seguridad de la información.
riesgos, como la falta de recursos humanos, fondos, conciencia de gestión y herramientas y soluciones.
Mientras tanto, la tecnología avanzada y el mayor acceso del usuario final a información crítica y sensible
continúan proliferando los riesgos de seguridad de la información.
Acceso no autorizado a programas o datos

Los sistemas de aplicación deben construirse con varios niveles de autorización para el envío de transacciones.
sion y aprobacion. Una vez que una aplicación entra en producción, los programadores ya no deberían
tener acceso a programas y datos. Si se proporciona acceso a los programadores, dicho acceso debe ser un
Acceso de "solo lectura" con el fin de comprender los problemas informados por el usuario.
Del mismo modo, el acceso de los usuarios debe limitarse a la "necesidad de saber". Esto significa que la información
información puesta a disposición de un usuario, ya sea de "solo lectura" o con acceso abierto para su modificación,
debe estar de acuerdo con las funciones y responsabilidades laborales del usuario. Por ejemplo, una nómina
El empleado necesita acceso al sistema de nómina, pero no al sistema de facturación.
Acceso remoto no autorizado

Cada vez más usuarios exigen acceso remoto a los recursos informáticos de las organizaciones. Remoto
El acceso permite a los usuarios dentro de una organización acceder a su red y recursos informáticos desde
ubicaciones fuera de las instalaciones de la organización. El acceso remoto, si no está autorizado, representa un
riesgo porque los dispositivos cliente (utilizados para el acceso remoto) tienden a tener una protección más débil que los est
dispositivos cliente basados en la organización o dard. Estos dispositivos no necesariamente pueden ser administrados por el
organización y, por lo tanto, no estar definido bajo las reglas de firewalls y antivirus, por ejemplo.
Las comunicaciones de acceso remoto pueden realizarse a través de redes no confiables, lo que
comunicación a supervisión, pérdida o manipulación no autorizadas. En otras palabras, si los usuarios de
(o fuera) de la red de la organización iban a obtener acceso no autorizado:
◾ la información sensible y confidencial puede estar en riesgo y verse afectada negativamente; y

◾ Se pueden introducir virus informáticos que afecten los archivos de la empresa, el rendimiento de la computadora.
sistemas, o simplemente ralentizar la red y sus recursos.
Para combatir el acceso remoto no autorizado, como mínimo, las ID de usuario y las contraseñas deben usar
cifrado cuando se transmite a través de líneas públicas. Además, los datos confidenciales que se transfieren
mitted sobre líneas públicas también debe estar encriptado. La solución de seguridad de cifrado depende de
la sensibilidad de los datos que se transmiten. Por último, las revisiones de acceso de los usuarios deben
realizado por el personal de seguridad de SI, y aprobado por la gerencia, para garantizar el acceso remoto
otorgada es precisa y consistente con las tareas y responsabilidades del trabajo.
Información inexacta
Debe garantizarse una información precisa si el usuario final accede a los datos de una aplicación.
ción, una base de datos departamental o información en la nube. Es posible que se solicite a los usuarios finales que generen
Página 270
informes para análisis e informes sin comprender completamente la información descargada.

Los repositorios de datos departamentales (por ejemplo, bases de datos, nubes de datos, etc.) pueden tener información redu
mación con diferentes marcos de tiempo. El resultado es una pérdida de tiempo al conciliar estos repositorios con
determinar qué datos son precisos. Otra área importante de preocupación es que la gestión puede fallar
utilizar la información correctamente debido a fallas en la identificación de información significativa; interpretar
significado y valor de la información adquirida; y / o comunicar información crítica al
gerente responsable o principal responsable de la toma de decisiones de manera oportuna.
Entrada de datos errónea o falsificada

La entrada de datos erróneos ocurre cuando se ingresan datos inexactos en el sistema de aplicación sin intención.
aliado debido a un error humano. Las medidas preventivas incluyen controles de aplicación integrados, como
dígitos y doble entrada. La entrada de datos falsificados, por otro lado, es cuando se introducen datos inexactos.
atado al sistema de solicitud intencionalmente para defraudar a la organización o sus partes interesadas. En esto
caso, las medidas preventivas pueden incluir salvaguardar el acceso a programas y datos a través del usuario
Mecanismos de autenticación y autorización.
Procesamiento incompleto, duplicado e inoportuno

El procesamiento incompleto ocurre cuando las transacciones o los archivos no se procesan debido a errores. Puede
ocurrir en el procesamiento por lotes cuando un archivo no está presente, o durante el procesamiento en línea cuando una
o el gatillo no inicia una transacción. El procesamiento de transacciones duplicadas incluye la ejecución de transacciones
acciones más de una vez. Puede ocurrir durante el procesamiento por lotes si los archivos se ejecutan varias veces,
o durante el procesamiento en línea cuando un disparador de transacción inicia una transacción más de una vez.
El procesamiento duplicado también puede ocurrir cuando un trabajo termina anormalmente (termina anormalmente), pero a
los registros que se han procesado no se restablecen. El procesamiento inoportuno incluye el procesamiento retrasado
debido a problemas de producción o falta de tiempo límite. Por ejemplo, los procesos financieros deben ocurrir
al cierre de fin de mes para asegurar que las transacciones detalladas procesadas en un sistema de aplicación
Haga coincidir la contabilización de la transacción con el libro mayor . Además, cuando un sistema en línea publica
transacciones a un sistema por lotes, generalmente hay una hora de corte en la que el procesamiento termina el día uno y
comienza para el segundo día.
Fallo del sistema de comunicaciones

Hoy en día, los sistemas de aplicaciones dentro de los entornos de TI son responsables de muchos servicios críticos,
incluidos los servicios de comunicación (por ejemplo, correo electrónico, intranets, Internet, mensajería instantánea, etc.).
Debido a esta creciente dependencia de los servicios de comunicación de TI, el posible fallo de estos
Los servicios presentan una fuente creciente de riesgo para las organizaciones. Información que se enruta desde
un lugar a otro sobre las líneas de comunicación es vulnerable a fallas accidentales, intencionales
interceptación y / o modificación por parte de personas no autorizadas.
Salida inexacta o incompleta

Si no se protege adecuadamente, los informes de salida pueden contener errores después del procesamiento (comprometiend
su integridad) y también se distribuyan de forma incorrecta. Los controles de salida deben estar en su lugar, por
Por ejemplo, para verificar que los datos sean precisos y completos (es decir, debidamente registrados), y que el informe
Los procedimientos de retribución y retención son eficaces. Ejemplos de controles de salida implican realizar
Página 271
revisiones, conciliaciones y verificación de transmisión de datos. Además, el acceso a los informes debe
basarse en la "necesidad de saber" para mantener la confidencialidad.
Documentación insuficiente
Los usuarios finales suelen centrarse en resolver una necesidad empresarial y es posible que no reconozcan la importancia d
documentación. Cualquier sistema de aplicación que sea utilizado por varios usuarios o que tenga beneficios a largo plazo.
deben estar documentados, especialmente si el desarrollador o programador original ya no está disponible
poder. La documentación proporciona a los programadores suficiente información para comprender cómo
La aplicación funciona y ayuda a resolver problemas para asegurar un análisis eficaz y eficiente de
Gram cambios y solución de problemas. La documentación debe actualizarse a medida que el sistema de solicitud
es modificado.
La documentación asegura además la mantenibilidad del sistema y sus componentes y
minimiza la probabilidad de errores. La documentación debe basarse en un estándar definido y
constan de descripciones de procedimientos, instrucciones al personal, diagramas de flujo, diagramas de flujo de datos,
diseños de pantalla o informe y otros materiales que describen el sistema de aplicación.
Riesgos de las aplicaciones de desarrollo del usuario final

El desarrollo del usuario final (EUD) (también conocido como informática del usuario final) generalmente implica el uso de
Aplicaciones desarrolladas por el departamento, como hojas de cálculo y bases de datos, que se utilizan con frecuencia.
como herramientas en el desempeño del trabajo diario. Estas hojas de cálculo y bases de datos son esencialmente una extens
El entorno de TI y los resultados generados a partir de ellos se pueden utilizar para tomar decisiones comerciales.
impactando a la empresa. Como resultado, el uso de DUE ha ampliado el alcance de las auditorías fuera del
entorno central de SI. El nivel de riesgo y los controles necesarios a implementar dependen de
la criticidad de la aplicación DUE. Por ejemplo, una aplicación EUD que consolida datos
de varios departamentos que luego serán una entrada en el sistema de informes financieros es un
objetivo de una auditoría.
Los riesgos de la aplicación de EUD no se identifican fácilmente debido a la falta de conciencia y la ausencia
de recursos adecuados. Por ejemplo, ordenadores personales o PC, portátiles, portátiles y dispositivos móviles.
Los dispositivos que alojan hojas de cálculo y / o bases de datos relevantes desarrolladas por el departamento pueden percibi
herramientas de productividad personal y, por lo tanto, la organización las ignorará en gran medida. Del mismo modo, much
nizaciones tienen procedimientos formales limitados o nulos relacionados con la DUE. El control o revisión de informes
producidas por las aplicaciones de EUD pueden ser limitadas o inexistentes. El riesgo asociado es que la gestión
El ment puede depender de informes e información desarrollados por el usuario final en el mismo grado que los
desarrollado bajo el entorno tradicional de SI centralizado. La gerencia debe considerar los niveles
de riesgo asociado con las aplicaciones de DUE y establecer niveles apropiados de controles. Común
Los riesgos asociados con los sistemas de aplicación de DUE incluyen:
◾ Mayores costos organizacionales

◾ Sistemas incompatibles
◾ Sistemas redundantes
◾ Ausencia de segregación de funciones
◾ Análisis del sistema incompleto
◾ Acceso no autorizado a datos o programas
Página 272
◾ Violaciones de derechos de autor

◾ Falta de opciones de respaldo y recuperación
◾ Destrucción de información por virus informáticos
Costos organizacionales más altos
Al principio, la EUD puede parecer relativamente económica en comparación con el desarrollo de TI tradicional.
Sin embargo, una serie de costos ocultos están asociados con la DUE que las organizaciones deben considerar.
Además de los costos de operación, los costos pueden aumentar debido a la falta de capacitación y soporte técnico. Ausencia
capacitación del usuario final y su inexperiencia también puede resultar en la compra de
software y la implementación de soluciones de software que son incompatibles con la organización
arquitectura de sistemas. Los usuarios finales también pueden incrementar los costos organizacionales creando ineficacia o
aplicaciones redundantes.
Sistemas incompatibles
Los sistemas de aplicaciones diseñados por el usuario final que se desarrollan de forma aislada pueden no ser compatibles co
arquitecturas de TI organizativas existentes o futuras. El desarrollo de sistemas de TI tradicionales verifica
compatibilidad con hardware existente y aplicaciones de software relacionadas. La ausencia de hardware
y los estándares de software pueden resultar en la imposibilidad de compartir datos con otras aplicaciones en el
organización.
Sistemas redundantes
Además de desarrollar sistemas incompatibles, los usuarios finales pueden estar desarrollando aplicaciones redundantes.
ciones o bases de datos debido a la falta de comunicación entre departamentos. Debido a esto
falta de comunicación, los departamentos de usuarios finales pueden crear una nueva base de datos o aplicación que
puede que ya se haya creado otro departamento. Un proceso de implementación más eficiente ha terminado
departamentos de usuarios coordinando sus proyectos de desarrollo de sistemas con TI y reuniéndose con
otros departamentos de usuarios finales para discutir sus proyectos propuestos.
Implementaciones ineficaces
Los usuarios finales suelen utilizar lenguajes de programación de cuarta generación, como bases de datos o Internet.
Herramientas de desarrollo web para desarrollar aplicaciones. En estos casos, el usuario final suele ser autodidacta.
Sin embargo, carecen de capacitación formal en el desarrollo de aplicaciones estructuradas, no se dan cuenta de la
importancia de la documentación, y tienden a omitir las medidas de control necesarias que se requieren para
implementaciones efectivas. Además, no hay segregación de funciones. Por insuficiente
análisis, documentación y pruebas, los sistemas desarrollados por el usuario final pueden no cumplir con las
Expectativas.
Ausencia de segregación de funciones

El desarrollo de sistemas de aplicaciones tradicionales está separado por función, y probado y completado por
expertos capacitados en cada área. En muchos proyectos de EUD, una persona es responsable de todas las fases, como
como analizar, diseñar, construir, probar e implementar el ciclo de vida del desarrollo. Allí
son riesgos inherentes, como pasar por alto errores, cuando la misma persona crea y prueba
Página 273
un programa. Es más probable que una revisión independiente detecte errores cometidos por el usuario final.
desarrollador, y dicha revisión ayuda a garantizar la integridad del sistema de aplicación recientemente diseñado.
Análisis del sistema incompleto
Los departamentos de usuarios finales eliminan muchos de los pasos establecidos por los departamentos centrales de TI. por
Por ejemplo, la fase de análisis del desarrollo puede estar incompleta y no todas las facetas de un problema
debidamente identificado. Además, con especificaciones incompletas, el sistema completo puede
No cumplir objetivos ni solucionar el problema empresarial. Los usuarios finales deben definir sus objetivos para
aplicación en particular antes de que decidan comprar software existente, haga que TI desarrolle la aplicación
catión, o utilizar su experiencia limitada para desarrollar la aplicación. Las especificaciones incompletas
probables deficiencias del sistema.
Acceso no autorizado a datos o programas

Los controles de acceso proporcionan la primera línea de defensa contra los usuarios no autorizados que acceden a
los programas y datos de un sistema de aplicación. El uso de controles de acceso, como ID de usuario y contraseña
palabras, son típicamente débiles en los sistemas desarrollados por el usuario. En algunos casos, los ID de usuario y las cont
ni siquiera serían necesarios, o serían muy simples y fáciles de adivinar. Este descuido puede someter
aplicaciones a cambios o eliminaciones accidentales o deliberadas que amenacen la confiabilidad de cualquier
información generada. Los sistemas requieren protección adicional para evitar cambios inesperados.
Para evitar cambios accidentales, el usuario debe limitarse a ejecutar únicamente.
Violaciones de derechos de autor

Las organizaciones son responsables de controlar el entorno informático para evitar que el software
piratería y violaciones de derechos de autor. Sin embargo, algunas organizaciones pueden no abordar específicamente
piratería de productos en la formación, en políticas y procedimientos, o en la aplicación de controles internos generales.
Dado que los programas de software se pueden copiar o instalar fácilmente en varias computadoras, muchas organizaciones
ciones violan las leyes de derechos de autor y ni siquiera son conscientes de los riesgos potenciales.
Las organizaciones enfrentan una serie de riesgos adicionales cuando toleran la piratería de software. Copiado
el software puede no ser confiable y contener virus. Los litigios que involucran violaciones de derechos de autor son altamen
publicitado, y la organización corre el riesgo de perder un fondo de comercio potencial. Además, tolerar
La piratería de software fomenta el deterioro de la ética empresarial que puede filtrarse a otras áreas del
organización.
Las organizaciones deben informar a los usuarios finales sobre las leyes de derechos de autor y las posibles consecuenci
que resultan de violaciones de esas leyes. Para evitar la instalación de software no autorizado, orga-
nizaciones pueden restringir la capacidad del usuario para instalar software al deshabilitar el acceso administrativo a sus
PC. Además, cuando los usuarios tienen acceso a una computadora personal o de escritorio, deben
firmar un reconocimiento que enumera el software instalado, las responsabilidades del individuo y cualquier
acción disciplinaria por violaciones. Los procedimientos escritos deben definir claramente la responsabilidad del usuario
mantener un inventario de software, auditar el cumplimiento y eliminar software sin licencia.
Falta de opciones de respaldo y recuperación

Las organizaciones que no mantienen una copia de sus datos realmente están buscando problemas. Hoy en día
Es extremadamente fácil perder datos y casi imposible reconstruir esos datos si no se hubieran realizado copias de seguridad
Página 274
realizado. Las aplicaciones de EUD a menudo se almacenan en la PC de uno y no se respaldan adecuadamente. En caso de
un desastre o un ataque de virus, estas aplicaciones (y sus datos) pueden no ser recuperables debido a la
falta de copias de seguridad. Por lo tanto, es posible que el usuario final no pueda volver a crear la aplicación y su
datos dentro de un período de tiempo razonable.
La ausencia de una estrategia de respaldo y recuperación da como resultado la pérdida de datos informáticos. Sin respal
los datos están constantemente sujetos a riesgos, como la eliminación accidental de archivos, virus y
hardware, fallas en el disco duro, fallas de energía o choques, robo de computadora, daños por agua, fuego y
muchos otros.
Destrucción de información por virus informáticos

La mayoría de los usuarios finales conocen los ataques de virus informáticos, pero el efecto de un virus permanece
sólo una amenaza hasta que realmente experimenten una pérdida. Basado en el informe de amenazas de McAfee Labs para
Diciembre de 2016, el número de ataques se aproxima a los 650 millones. Para dispositivos móviles, el número
para 2016 también es significativo, casi acercándose a la marca de 13,5 millones. Además, en sus amenazas de 2017
Informe de predicciones, McAfee Labs predice lo siguiente, entre otros:
◾ Los atacantes seguirán buscando oportunidades para romper las computadoras tradicionales (no móviles)
sistemas y explotar vulnerabilidades. Los atacantes son capaces de explotar sistemas cuya empresa
Ware (software permanente programado en una memoria de solo lectura) controla la entrada y la salida
operaciones, así como otro firmware, como unidades de estado sólido , tarjetas de red y Wi-Fi
dispositivos. Es probable que estos tipos de exploits aparezcan en ataques de malware comunes .
◾ El ransomware en dispositivos móviles continuará su crecimiento, aunque es probable que los atacantes
combinar estos bloqueos de dispositivos móviles con otras formas de ataque, como el robo de credenciales,
para acceder a cosas como cuentas bancarias y tarjetas de crédito.
Un virus es el término común que se usa para describir programas de reproducción automática, gusanos , lunares , agujeros
Caballos de Troya y bombas de tiempo . En el entorno actual, la amenaza es alta debido a la
citado número de fuentes desde las que se puede introducir un virus. Por ejemplo, los virus se pueden copiar
desde un disco o descargado de una página web infectada. Se propagan a otros archivos, esos archivos en
convertir la propagación a otros archivos, y así sucesivamente. El sector de arranque de un disco es uno de los más suscept
infección de virus porque se accede a él cada vez que se enciende la computadora, lo que
replicación del virus. Cuando se activa un virus, copia el código en el disco duro y puede
propagarse a medios adicionales mediante la ejecución de una aplicación común, como un procesador de texto o correo
programa. Los medios que contienen el virus continuarán infectando otras computadoras y propagarán la
virus en toda una organización.
Los virus también pueden propagarse entre equipos conectados dentro de una red (local, Internet, etc.).
Pueden propagarse cuando se descargan archivos o programas infectados desde una computadora pública a través de
archivos adjuntos a correos electrónicos, código oculto dentro de hipervínculos, etc. Los virus pueden causar una variedad d
problemas como:
◾ Destruir o alterar datos

◾ Destruyendo hardware
◾ Visualización de mensajes no deseados
◾ Hacer que los teclados se bloqueen y se vuelvan inactivos
◾ Reducir la velocidad de una red al realizar muchas tareas que en realidad son solo un bucle continuo
sin fin ni resolución
Página 275
◾ Produciendo spam
◾ Lanzar ataques de denegación de servicio
El riesgo ypara
sistemas las organizaciones
la reconstrucción es eldañados.
de datos tiempo necesario para eliminar
Las organizaciones el virus
también y reconstruir
deben los por el envío
preocuparse
enviar programas infectados con virus a otras organizaciones. Los virus causan daños económicos importantes,
y los destinatarios pueden presentar demandas contra la organización instituyente.
Riesgos para los sistemas que intercambian información comercial electrónica

El intercambio electrónico de datos (EDI) se refiere al intercambio electrónico de documentos comerciales.
entre socios comerciales (o comerciales) utilizando un formato estandarizado. EDI permite a las organizaciones
enviar y recibir información electrónicamente en un formato estándar para que las computadoras puedan leer
y comprender los documentos que se intercambian. Un formato estándar describe el tipo, también
como el diseño, estilo o presentación (por ejemplo, entero, decimal, mmddyy, etc.) de la información que se
negociado. Los ejemplos comunes de información comercial intercambiada a través de EDI incluyen facturas y
ordenes de compra. El Anexo 9.1 describe los riesgos asociados con EDI o sistemas de intercambio electrónico
información de negocios.
Anexo 9.1 Riesgos de EDI o sistemas que intercambian información comercial electrónica
Riesgo Descripción
Pérdida de negocio Corrupción involuntaria o deliberada de aplicaciones relacionadas con EDI

continuidad / marcha podría afectar a todas las transacciones de EDI realizadas por una organización,
problema de preocupación impactando la satisfacción del cliente, las relaciones con los proveedores y posiblemente
continuidad del negocio eventualmente.
Interdependencia Existe una mayor dependencia de los sistemas de los socios comerciales,
que está más allá del control de la organización.
Pérdida de confidencialidad La información confidencial puede ser divulgada accidental o deliberadamente

de sensible en la red o en el sistema de almacenamiento del buzón de correo a personas no autorizadas
información partes, incluidos los competidores.
Mayor exposición a El acceso a los sistemas informáticos puede brindar una mayor oportunidad
fraude para cambiar los registros informáticos de una sola organización y
la de sus socios comerciales por el personal de las partes comerciales o por
personal de la red de terceros. Esto podría incluir la introducción de
transacciones no autorizadas por parte de la organización usuaria o de un tercero
personal.
Manipulación de Una situación en la que los importes cobrados o pagados a los proveedores no son
pago revisado antes de la transmisión. Por tanto, existe el riesgo de que
Se pueden realizar pagos por bienes no recibidos, pago
los montos pueden ser excesivos o pueden producirse pagos duplicados.
Pérdida de transacciones Las transacciones podrían perderse como resultado de interrupciones en el procesamiento en
sitios de red de terceros o en ruta a la organización receptora,
lo que podría causar pérdidas e información financiera inexacta.
( Continuacion )
Página 276
Anexo 9.1 ( continuación ) Riesgos de EDI o sistemas que intercambian información comercial electrónica
Riesgo Descripción
Errores en la información Errores en los sistemas de procesamiento y comunicaciones, como
y comunicación reparación de mensajes incorrectos, puede resultar en la transmisión de
sistemas información comercial incorrecta o informes inexactos a
administración.
Pérdida de pista de auditoría EDI elimina la necesidad de una copia impresa. Habrá menos papel para
los auditores para verificar. Es posible que el usuario de EDI no proporcione
evidencia de auditoría adecuada, ya sea en papel o en formato electrónico
medios de comunicación. El proveedor externo no puede mantener pistas de auditoría para un
un período de tiempo significativo, o las pistas de auditoría podrían perderse cuando
los mensajes se pasan a través de múltiples redes.
Concentración de Habrá una mayor dependencia de los controles informáticos donde

controlar reemplace los controles manuales, y es posible que no sean lo suficientemente oportunos.
El uso de EDI con su mayor dependencia de los sistemas informáticos.
concentra el control en manos de menos personal, aumenta la confianza
en personas clave y aumenta el riesgo.
Fallo de la aplicación Las fallas de aplicaciones o componentes EDI podrían tener un impacto significativo
impacto negativo en las organizaciones asociadas dentro de los respectivos
ciclos económicos, especialmente para la gestión de inventario Just-In-Time ,
sistemas de producción y pago. Además, hay un
posibilidad de propagación de errores a través de otros sistemas debido a
integración con otras aplicaciones comerciales.
Responsabilidad legal potencial Una situación en la que la responsabilidad no está claramente definida en el socio comercial
acuerdos, la responsabilidad legal puede surgir debido a errores fuera del
control de una organización o por sus propios empleados. Todavía hay
considerable incertidumbre sobre el estado legal de los documentos EDI
o la incapacidad de hacer cumplir los contratos en circunstancias imprevistas.
Sobrecarga por Los proveedores externos pueden cobrar de forma accidental o deliberada
servicio de terceros una organización que utiliza sus servicios.
proveedores
Manipulación de La información disponible para los propietarios de terceros

organización las redes pueden permitirles a ellos oa sus competidores tomar
ventaja de una organización.
No lograr Sucede donde los ahorros de costos anticipados de la inversión en

costo anticipado Los EDI no son realizados por alguna razón por una organización.
ahorros
Las implicaciones que surgen de estos riesgos incluyen:
◾ Pérdida potencial de la pista de auditoría de transacciones, lo que dificulta o imposibilita la

cile, reconstruya y revise los registros. Esto posiblemente podría ser una infracción de la legislación y resultar
en procesamiento y multas.
Página 277
◾ Mayor exposición al rescate, chantaje o fraude a través de una posible interrupción de los servicios.
o mayores oportunidades para alterar los registros informáticos en una organización y su comercio
SI de los socios.
◾ Interrupción de los flujos de efectivo cuando las transacciones de pago se generan por error o se desvían o
manipulado.
◾ Pérdida de rentabilidad que se produce a través de un aumento de los cargos por intereses u órdenes que van a
competidor debido a la falta de recepción de mensajes EDI.
◾ Daño a la reputación debido a la pérdida de clientes importantes, especialmente si los problemas de EDI son
ampliamente publicitado.
Estándares para evaluaciones de auditoría EDI

Los auditores, la gerencia, los desarrolladores y los consultores de seguridad deben estar al tanto del negocio.
riesgos asociados con los sistemas EDI. Algunos estándares bien conocidos que proporcionan una base para EDI
Las evaluaciones de auditoría incluyen: el grupo de estándares X12 del Comité de Estándares Acreditados (ASC)
portado por el American National Standards Institute (ANSI) de Norteamérica y el Electronic
Estándares internacionales de intercambio de datos para la administración, el comercio y el transporte (EDIFACT)
con el apoyo de la Comisión Económica para Europa de las Naciones Unidas.
◾ Los estándares ASC X12 facilitan el intercambio electrónico de transacciones comerciales, como
realizar y procesar pedidos, enviar, recibir, facturar y pagar. Específicamente,
Los estándares ASC X12 identifican los datos que se utilizan en la transacción, el orden en el que se
los datos deben aparecer, ya sean obligatorios u opcionales, cuando los datos pueden repetirse, y
cómo se estructuran y utilizan los bucles, si procede.
◾ Los estándares EDIFACT proporcionan un conjunto de estándares internacionales comunes para los
transmisión de datos comerciales. Las normas internacionales EDIFACT se ocupan de las
intercambio trónico de datos estructurados, como el comercio de bienes y servicios entre
sistemas de información computarizados independientes.
Otros estándares importantes comunes para las evaluaciones de EDI incluyen:
◾ Estándar de Tradacoms, predominante en el sector minorista del Reino Unido. los

El estándar actualmente se conoce como GS1 UK.
◾ Los estándares de la Organización para el intercambio de datos por teletransmisión (ODETTE), que
representar los intereses de la industria del automóvil en Europa. ODETTE crea estándares
dards, desarrolla las mejores prácticas y proporciona servicios que apoyan la gestión logística,
comunicaciones de comercio electrónico e intercambio de datos de ingeniería en todo el
industria automotriz.
◾ Las normas y las mejores prácticas de Verband der Automobilindustrie (VDA) también son aplicables
para la industria automovilística europea. Los estándares VDA se centran particularmente en servir
necesidades de las empresas de automoción alemanas.
◾ Los estándares internacionales Health Level-7 (HL7) se relacionan con el intercambio electrónico de
y datos administrativos entre los proveedores de atención médica. Los estándares HL7 han sido adoptados por
otros organismos emisores de normas como ANSI y la Organización Internacional de Normalización.
◾ Los estándares globales GS1 EDI guían la comunicación electrónica y la automatización de negocios.
transacciones que normalmente tienen lugar en toda la cadena de suministro. Estos estándares se aplican
a minoristas, fabricantes, proveedores de materiales y proveedores de servicios logísticos, por ejemplo.
Página 278
Riesgos de las aplicaciones web

PC Magazine define una aplicación web como "una aplicación en la que todas o algunas partes del software
los productos se descargan de la Web cada vez que se ejecutan ". * El uso de aplicaciones web se ha convertido en un
estrategia clave para la dirección de muchas empresas. Algunas empresas simplemente utilizan aplicaciones web para
con fines de marketing, pero la mayoría los utiliza para reemplazar las aplicaciones cliente-servidor tradicionales. Otro
Las características de las aplicaciones web incluyen el uso de un navegador web en el lado del cliente que es
generalmente es independiente de la plataforma y requiere menos potencia informática. Algunos otros beneficios de la Web
Las aplicaciones incluyen reducción del tiempo de comercialización, mayor satisfacción del usuario y reducción de gastos.
relacionados con el mantenimiento y los soportes.
Desde el punto de vista del desarrollo, una aplicación web debe diseñarse para realizar las
tareas específicas acordadas y documentadas como parte de los requisitos funcionales. Al desarrollar
Aplicaciones web, los equipos deben comprender que los controles del lado del cliente, como la validación de entrada, están
Los campos y los controles de interfaz, por ejemplo, no son completamente confiables por motivos de seguridad. Atacantes
puede eludir fácilmente estos controles del lado del cliente y obtener acceso para analizar o manipular la aplicación
tráfico, envío de solicitudes, etc. Prácticas conocidas a las que se hace referencia al desarrollar aplicaciones web
Los sistemas o aplicaciones incluyen las 10 mejores prácticas de codificación segura, publicadas en marzo de 2011 por
el Equipo de preparación para emergencias informáticas de los Estados Unidos (US-CERT). Otras prácticas habituales
incluir los principios de codificación segura descritos en el Proyecto de seguridad de aplicaciones web abiertas
(OWASP) Pautas de codificación segura. Si bien los siguientes principios de codificación segura de OWASP especifican
Específicamente como referencia a aplicaciones web, estos principios también pueden aplicarse a aplicaciones no web.
◾ Validación de entrada
◾ Codificación de salida
◾ Gestión de autenticación y contraseña
◾ Gestión de sesiones
◾ Control de acceso
◾ Prácticas criptográficas
◾ Manejo y registro de errores
◾ Protección de datos
◾ Seguridad de la comunicación
◾ Configuración del sistema
◾ Seguridad de la base de datos
◾ Gestión de archivos
◾ Gestión de la memoria
◾ Prácticas generales de codificación
OWASP ofrece una lista de verificación práctica † que se centra en implementar prácticas de codificación seguras y
principios. La lista de verificación está diseñada para servir como una herramienta de inicio de codificación segura para ayud
Los equipos comprenden (y cumplen) las prácticas de codificación segura.
Riesgos atribuibles a las aplicaciones web, como se indica en el Top 10 Most Critical 2017 de OWASP
Los riesgos de seguridad de las aplicaciones web ‡ incluyen:
* www.pcmag.com/encyclopedia/term/54272/web-application.
† www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf.
‡ www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2017_Release_
Candidato.
Página 279
◾ Inyección
◾ Autenticación y gestión de sesiones rotas
◾
◾ Secuencias de comandos
Control de acceso roto entre sitios
◾ Mala configuración de seguridad
◾ Exposición de datos sensibles
◾ Protección contra ataques insuficiente
◾ Falsificación de solicitudes entre sitios
◾ Usar componentes con vulnerabilidades conocidas
◾ Bajo interfaces de programa de aplicación protegidas
La lista de verificación de prácticas y principios de codificación segura de OWASP es una forma eficaz de minimizar
riesgos y asegurar que la organización desarrolle aplicaciones web exitosas. Sin embargo, los auditores,
La administración, los desarrolladores y los consultores de seguridad deben considerar los niveles de riesgos asociados con
todo tipo de aplicaciones con el fin de diseñar e implementar controles de aplicación adecuados.
Controles de aplicación
Hay dos grandes grupos de controles informáticos que ayudan a mitigar la aplicación
riesgos discutidos anteriormente, y son esenciales para asegurar el funcionamiento adecuado continuo de la aplicación
sistemas. Ellos son: Controles generales de computadora y Controles de aplicación. Computadora general
controles ("controles generales" o "ITGC") incluyen el examen de políticas y procedimientos que se relacionan
a muchas aplicaciones y apoya el funcionamiento eficaz de los controles de aplicación. General
Los controles cubren la infraestructura de TI y los servicios de soporte, incluidos todos los sistemas y aplicaciones.
ciones. Los controles generales comúnmente incluyen controles sobre (1) operaciones de sistemas de información;
(2) seguridad de la información; y (3) gestión de control de cambios (es decir, adquisición de software del sistema,
cambio y mantenimiento, cambio de programa y adquisición de sistemas de aplicación, desarrollo y
mantenimiento).
Los controles de la aplicación examinan los procedimientos específicos y únicos de la aplicación. Solicitud
Los controles también se denominan "controles automatizados". Se preocupan por la exactitud,
integridad, vigencia y autorización de los datos capturados, ingresados, procesados, almacenados, transmitidos
ted, e informó. Ejemplos de controles de aplicación incluyen validar la entrada de datos, verificar
precisión matemática de los registros y realización de verificaciones de secuencia numérica, entre otros.
Es probable que los controles de aplicación sean efectivos cuando los controles generales son efectivos. Figura 1.3 de
El capítulo 1 ilustra los controles generales y de aplicación, y cómo deben estar en su lugar para
para mitigar los riesgos y proteger las aplicaciones. Observe en la exposición que el sistema de solicitud es
constantemente rodeado de riesgos. Los riesgos se representan en la exposición mediante símbolos de explosión. Estas
los riesgos pueden ser en forma de acceso no autorizado, pérdida o robo o equipo e información,
apagado del sistema, etc. Los controles generales, que se muestran en los símbolos hexagonales, también rodean el
aplicación y proporcionar un "escudo protector" contra los riesgos. Por último, están la aplicación o
controles automatizados que residen dentro de la aplicación y brindan protección de primera mano sobre el
entrada, procesamiento y salida de la información.
Los controles de aplicación implementados en las organizaciones pueden incluir, entre otros, sistemas y / o
controles de configuración de aplicaciones; controles relacionados con la seguridad que imponen el acceso de los usuarios, l
reglamento de deberes; y controles de notificación automatizados para alertar a los usuarios de que una transacción o proces
está esperando su acción. Los controles de la aplicación también verifican los cálculos matemáticos, el equilibrio
Página 280
totales entre trabajos, razonabilidad frente a volúmenes o valores esperados, conciliaciones entre
sistemas, y la distribución controlada de la salida para asegurar la precisión y la integridad de las transacciones
ciones.
y salidaLos controles deen
de información aplicación se pueden
una aplicación. describirencomo
Se dividen técnicas utilizadas
tres categorías para controlar la entrada, el procesamiento,
principales:
controles de entrada, procesamiento y salida.
Controles de entrada
Los controles de entrada están destinados a minimizar los riesgos asociados con la entrada de datos en los sistemas de aplica
La "interfaz de usuario" es el medio por el cual el usuario interactúa con el sistema. En la mayoría de los casos, esto
es la pantalla de la computadora, el mouse y el teclado. Una interfaz eficaz para los usuarios ayudará a reducir
costos de escritorio y mejorar la precisión y la eficiencia. Además, una interfaz de usuario debe proporcionar un medio para
el usuario para obtener ayuda contextual.
La definición de los requisitos de entrada asegura que el método de captura de datos sea apropiado
para el tipo de datos que se ingresan y cómo se utilizan posteriormente. Problemas de rendimiento y
Se pueden introducir problemas de precisión con métodos inapropiados para capturar datos. Requisito de entrada
Los comentarios deben especificar todas las fuentes válidas de datos, así como el método para validar los datos. Entrada
Los controles evitan que se ingresen transacciones inválidas y previenen datos inválidos dentro de
actas. Garantizan específicamente la autenticidad, precisión e integridad de los datos ingresados.
en una aplicación.
Autenticidad
NIST define la autenticidad como “la propiedad de ser genuino y poder ser verificado y
de confianza ". * La autenticidad asegura que solo los usuarios autorizados tengan acceso para ingresar transacciones.
Durante el proceso de desarrollo de un sistema de aplicación, los usuarios autorizados deben definirse junto con
sus niveles de seguridad para el acceso a los datos. Esta información se puede utilizar al diseñar pantallas de entrada para
limitar pantallas o campos a grupos de usuarios particulares. Los controles también pueden diseñarse para hacer cumplir la s
ción de deberes. Por ejemplo, un usuario puede ingresar una transacción, pero un supervisor puede necesitar
aprobar la transacción antes de enviarla para su procesamiento.
También se debe considerar la autenticación cuando las aplicaciones automatizadas interactúan con otras
aplicaciones. La autenticación, según NIST, verifica "la identidad de un usuario, proceso o dispositivo
a menudo como un requisito previo para permitir el acceso a los recursos en un sistema de información ". * A menudo, progr
Los trabajos por lotes uled operan bajo la autoridad con privilegios de acceso específicos a la base de datos. Riesgos
asociados con estas cuentas de acceso, así como los privilegios de acceso, deben revisarse. Genérico
las cuentas no deben utilizarse. Los trabajos por lotes deben tener privilegios mínimos y nivel de sistema
las cuentas no deben utilizarse.
Exactitud
La precisión se garantiza mediante verificaciones de edición que validan los datos ingresados antes de aceptar la transacción
ción para su procesamiento. La precisión asegura que la información ingresada en una aplicación sea consistente
y cumple con las políticas y procedimientos. Esto se logra diseñando pantallas de entrada con
ediciones y validaciones que verifican los datos que se ingresan con reglas o valores predefinidos.
* http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
Página 281
La precisión de las transacciones procesadas se puede garantizar haciendo que todas las transacciones ingresadas
a través de verificaciones de validación de datos, ya sea que provengan de una pantalla en línea, una interfaz de otra
aplicación o generado por el sistema. Programas que generan transacciones automáticamente (es decir,
programas activados por tiempo) deben tener ediciones integradas que validen la precisión de la transacción similar a
transacciones ingresadas por un usuario. También es importante realizar un seguimiento del volumen y la frecuencia de las tr
contra las tendencias esperadas para garantizar que las transacciones se activen correctamente. Falta y duplicada
También se deben programar verificaciones en caso de que ocurra un error en la lógica de activación.
Las rutinas de edición y validación son generalmente exclusivas del sistema de aplicación que se utiliza,
aunque se pueden incorporar algunas rutinas de uso general. El Cuadro 9.2 enumera la edición y
Verificaciones o controles de rutina de validación al ingresar datos. Se colocan rutinas de edición y validación
en un sistema para ayudar a garantizar la integridad y precisión de los datos. Por lo tanto, editar
las rutinas no deben tomarse a la ligera. En la mayoría de los sistemas, el usuario no dispone de esta capacidad.
Solo se permite anular las rutinas de edición para los administradores o supervisores de departamento de usuarios privilegiad
y desde un terminal maestro. La aplicación debe registrar automáticamente las anulaciones para que
estas acciones pueden analizarse para determinar su idoneidad y corrección.
Lo completo
La integridad confirma que todos los datos necesarios para satisfacer las necesidades comerciales actuales y futuras son
realmente listo y disponible. Tener datos completos con los que trabajar ayuda a la administración al realizar
decisiones comerciales que afectan a la organización. Datos completos, en forma de estados financieros,
listas de proveedores, informes de cuentas por cobrar de clientes, informes de préstamos, etc., reflejan un estado preciso de l
nización y cómo está lidiando con la competencia y las tendencias y patrones de la industria. Lo completo
está garantizado, por ejemplo, a través de procedimientos de manejo de errores que proporcionan registro, informes y
corrección de errores.
Figura 9.2 Controles de edición y validación al ingresar datos
Controlar Descripción
Verificación de campo Confirma que los caracteres de un campo son del tipo adecuado.
Verificación de signo Valida que los datos en un campo tengan el positivo o negativo apropiado
firmar.
Límite o rango Verifica que la cantidad numérica ingresada esté dentro del mínimo aceptable
cheque y valores máximos.
Comprobación de tamaño Verifica que el tamaño de los datos ingresados se ajuste al campo específico.
Lo completo Corrobora que se ingresan todos los datos requeridos y necesarios.

cheque
Verificación de validez Compara los datos del archivo de transacciones con los del archivo maestro para verificar
existencia.
Sensatez Comprueba la corrección de la relación lógica entre dos elementos de datos.

cheque
Comprobar dígito Vuelve a calcular un dígito de control para verificar que no se haya cometido un error de entrada de datos.
verificación
Página 282
Controles de procesamiento
Los
tienecontroles de procesamiento
lugar. Estos previenen,
controles ayudan detectan
a garantizar y / datos
que los o corrigen errores de
se procesen durante el procesamiento
manera de datos (por lotes o en l
precisa y completa.
a través de la aplicación (por ejemplo, no se agregan, pierden ni alteran datos durante el procesamiento, etc.).
Los trabajos programados dentro de una aplicación deben revisarse para asegurarse de que los cambios que se
apropiado y no presente riesgos. Como ejemplo, en un sistema de aplicación ERP, una Estructura
El programa de lenguaje de consulta se puede escribir para modificar datos directamente contra la base de datos, evitando
los controles dentro de la aplicación y operando contra la base de datos con el administrador del sistema
privilegios. Sin embargo, desde la pantalla, este programa puede verse como un informe si el código subyacente es
no evaluado.
Precisión e integridad
Para asegurar la exactitud e integridad de los datos (A&C), los programas deben construirse con lógica para prevenir,
detectar y / o corregir errores. Los procedimientos de manejo de errores deben incluir:
◾ Registro de actividad de errores

◾ Aprobación de la corrección de errores y reenvío
◾ Responsabilidad definida de los archivos de suspenso
◾ Informes de errores no resueltos
◾ Envejecimiento y priorización de errores no resueltos
A&C también se puede lograr equilibrando las transacciones por lotes que entran con las transacciones que salen de
un predecesor. Los pasos de equilibrio deben ocurrir en los principales puntos de procesamiento del trabajo. El siguiente con
Los puntos son ejemplos de los principales puntos de procesamiento de trabajos:
◾ Puntos de entrada. Programas que aceptan transacciones del procesamiento de entrada (por ejemplo, interfaz de usuari
◾ Principales módulos de procesamiento. Los programas que modifican los datos (por ejemplo, realizan cálculos, etc.)
◾ Puntos de ramificación. Programas que dividen o fusionan datos (por ejemplo, un programa que fusiona datos de dos
o más fuentes de entrada diferentes en un archivo; El archivo se utiliza luego como fuente de datos para el
sistema de informes, etc.)
◾ Puntos de salida. Resultado del procesamiento de datos (por ejemplo, informes financieros u operativos, impresos
comprobaciones, archivo de datos de salida, etc.)
Diseñado correctamente, el equilibrio de los totales para el recuento y el monto de las transacciones puede detectar
transacciones duplicadas (ver Anexo 9.3, parte A). Además, el equilibrio y la reconciliación deben
ocurren entre aplicaciones que comparten datos comunes. Esto se puede lograr creando una reconciliación
informe de ación que enumera datos de todos los sistemas de aplicación involucrados e informa sobre cualquier diferencia
para que un grupo de usuarios revise y siga las excepciones. La figura 9.3, parte B se utiliza para ilustrar
Probar una conciliación de muestra entre los sistemas de facturación, pago y cuentas por cobrar.
Observe cómo el sistema de Cuentas por cobrar confirma (o concilia) los 17 registros involucrados y,
lo más importante, el saldo de $ 400 pendiente después de que se enviaron las facturas y los cobros (o
pagos) fueron recibidos.
Los totales de balance también deben incluir un recuento de transacciones (cantidad), los totales de todas las cantidades
campos para cada tipo de transacción y totales cruzados para campos de detalle a campos totales. darse cuenta
en la figura 9.4 cómo se verifica el número total de cantidad y cómo se verifica la cantidad total por pieza
Página 283
(un)
Sistema de cobranza- Sistema de cuentas por cobrar
facturas emitidas: facturas en:
Cuenta = 10 Cuenta = 10
Total = $ 1,250 Total = $ 1,250
(segundo)
Sistema de cobranza- Sistema de pago-

facturas emitidas: pagos en:
Recuento de registros = 10 Recuento de registros = 7

Suma récord = $ 1250 Suma récord = $ 850
Cuentas por cobrar

sistema
(reconciliación de
facturas y
pagos):
Recuento de registros = 17
Suma récord = $ 400
Figura 9.3 Totales de balance de lotes (A) y conciliación entre aplicaciones (B).
resulta de la cantidad cruzada y el precio unitario. En archivos donde no hay totales significativos,
Se pueden crear totales hash que sumen todas las cifras en una columna para verificar que el mismo total es
aceptado por el siguiente proceso. Por ejemplo, la suma de los números de pieza no proporciona ningún significado
En g. Sin embargo, este total se puede utilizar para verificar que se recibieron todos los números de pieza correctos.
Los flujos de transacciones deben equilibrarse a diario y de forma acumulativa a trabajos mensuales antes de la
el registro se cierra. Los totales de balance también deben considerar tanto las transacciones de error que salen como las que
el flujo de procesamiento. En el Cuadro 9.5, por ejemplo, 10 transacciones totales (con un monto de $ 1250)
menos 2 transacciones escritas en un archivo de error (con un monto de $ 250) se procesaron en las Cuentas
Sistema de cuentas por cobrar. El recuento total conciliado / equilibrado y el monto en las cuentas por cobrar
El sistema ahora es de ocho y $ 1,000, respectivamente.
Otros ejemplos comunes de controles de procesamiento incluyen:
◾ Coincidencia de datos . Coincide con dos o más elementos antes de ejecutar un comando o acción en particular
(por ejemplo, hacer coincidir la factura con la orden de compra y recibir el informe antes de realizar el pago,
etc.).
◾ Etiquetas de archivo . Asegúrese de que se esté utilizando el archivo correcto y más actualizado.
◾ Cruce de pies . Compara dos formas alternativas de calcular el mismo total para verificar
para mayor precisión (por ejemplo, agregar por filas y columnas en una hoja de cálculo, etc.).
Página 284
Figura 9.4 Muestras totales de balance

Orden Cantidad Número de pieza Precio unitario Total
Parte A 100 1288543 $ 1.20 120,00 $
Parte B 80 0982374 0,60 USD 48,00 $
Parte C 200 5436682 $ 0.45 $ 90.00
Total 380 $ 258.00
Sistema de cobranza- Archivo de error:

facturas emitidas: facturas:
Cuenta = 10 Cuenta = 2
Total = $ 1,250 Total = $ 250
Cuentas por cobrar

sistema
(facturas en — errores):
Cuenta = 8
Total = $ 1,000
Figura 9.5 Balance de totales con transacciones de error.
◾ Pruebas de balance cero . Compruebe que una cuenta en particular (por ejemplo, cuenta de compensación de nómina,
mantiene un saldo de cero. Esta prueba ayuda a las organizaciones a eliminar el exceso de saldos en
cuentas separadas y manteniendo un mayor control sobre los desembolsos.
◾ Mecanismos de protección contra escritura . Protéjase contra la sobrescritura o el borrado de datos.
◾ Controles de actualización concurrente . Evite errores de dos o más usuarios actualizando el mismo registro en
al mismo tiempo.
Controles de salida
Los controles de salida están diseñados para detectar y corregir errores después de que se completa el procesamiento, asegur
la integridad de la salida producida. En particular, los controles de salida incluyen: (1) procedimientos
para verificar si los datos son precisos y completos (es decir, si están debidamente registrados) y (2) procedimientos para
adecuada distribución y retención de informes. Si los productos se producen de forma centralizada, entonces los
los controles, como tener un oficial de seguridad y distribuir registros, pueden ser apropiados. Si salida
Página 285
se distribuye a través de una red de comunicación de datos, el énfasis del control cambia a los controles de acceso
para
Baseestaciones de trabajo
de "necesidad individuales. Para mantener la confidencialidad, el acceso a los informes debe basarse en un
de saber".
Precisión e integridad
La salida debe verificarse con una fuente independiente para verificar su precisión y
ness. Hay tres tipos comunes de controles de salida relacionados con la precisión y la integridad.
revisiones, conciliaciones y controles de transmisión de datos. Las opiniones de los usuarios garantizan los resultados (inform
generados son seguros, confidenciales y privados a través de la realización de equilibrio e integridad
cheques; comparaciones de campos de datos clave; verifica si falta información; y recreación de documentos.
Las conciliaciones incluyen procedimientos para conciliar los informes de control. Por ejemplo, totales de transacciones
contabilizado en el libro mayor debe conciliarse con el saldo adeudado detallado en las cuentas
libro mayor subsidiario de cuentas por cobrar . Otro ejemplo incluye conciliaciones de datos externos, como
conciliación de cuentas bancarias / en efectivo. Como se mencionó anteriormente, los datos que son comunes a dos o más
las aplicaciones deben conciliarse para verificar la coherencia. Se implementan controles de transmisión de datos
Mentado para proteger la transferencia física de datos a través de un punto a punto o punto a multipunto
canal de comunicación. Un ejemplo aquí sería la implementación de técnicas de cifrado.
sobre los datos transmitidos.
Distribución y retención
La distribución de la salida debe estar claramente definida y el acceso físico y lógico debe ser limitado.
a personal autorizado. La necesidad de resultados debe revisarse periódicamente ya que los informes pueden
solicitado en el momento en que se desarrolla una aplicación, pero puede que ya no sea útil. También el mismo
La información se puede utilizar para más de un sistema con diferentes vistas, organización y uso.
Por ejemplo, el departamento de marketing puede utilizar la información de ventas para pagar comisiones y
para las cuotas de ventas, mientras que el departamento de contabilidad utiliza la misma información para preparar
declaraciones e informes ciales. Estos dos sistemas deben conciliarse para asegurarse de que la cantidad
reportado para pagar al personal de ventas es el mismo que el monto reportado en los estados financieros y
informes.
Debido a que el espacio de almacenamiento (en línea o físico) es costoso, los períodos de retención y el almacenamiento
Deben definirse mentos para programas, datos e informes. La información crítica debe almacenarse
de forma segura (es decir, cifrada) y su destrucción debe ser permanente y llevarse a cabo de tal manera que
para evitar la visualización no autorizada. Las organizaciones deben considerar cualquier ley y reglamento que pueda
rigen la duración de los períodos de retención.
Participación del auditor de TI

Los auditores de TI pueden ayudar a las organizaciones revisando sus sistemas de aplicación para asegurarse de que cumplen
con la estrategia y los estándares de la organización, así como proporcionar funciones automatizadas para
apoyar activamente el proceso empresarial. Las aplicaciones deberán evaluarse los riesgos para determinar el nivel
de participación en la auditoría. El tipo de evaluación también variará dependiendo de los riesgos de la
solicitud. Las aplicaciones introducen riesgos para las organizaciones en forma de aumento de costos, pérdida de
integridad de los datos, debilidades en la confidencialidad, falta de disponibilidad, bajo rendimiento y otros.
Estos riesgos deben abordarse con una adecuada selección e implementación de controles.
Página 286
La auditoría de los sistemas de aplicación requiere conocimientos específicos sobre los riesgos y controles de la aplicaci
Comprenderlos permite al auditor de TI identificar áreas clave que se beneficiarían de la independencia
verificación de abolladuras. Además, comprender los controles de la aplicación permite al auditor de TI evaluar
y recomendar los que garantizarán un procesamiento de transacciones completo y preciso.
Como se indicó anteriormente, los auditores de TI pueden participar como consultores de control o revisores independie
ers. El nivel de participación se determina completando una evaluación de riesgos. Resultados del riesgo
La evaluación también indica la cantidad de tiempo necesaria para asignar a la aplicación en particular,
recursos necesarios, etc. A continuación, sigue la preparación de un plan de auditoría. El plan describe la auditoría
objetivos y procedimientos que se deben realizar para garantizar que las aplicaciones se implementen adecuadamente,
y salvaguardar la información. Los auditores de TI finalmente comunican los hallazgos identificados
la auditoría más recomendaciones a la dirección.
Los auditores de TI pueden no tener suficiente tiempo para evaluar cada sistema de aplicación particular en la organización.
zation. La participación en una aplicación en particular dependerá de la evaluación de la aplicación.
riesgos de Los riesgos de la aplicación se relacionan con la complejidad y magnitud de la aplicación, el personal sin experien
falta de participación del usuario final y falta de compromiso de la dirección. El nivel de riesgo puede ser un
función de la necesidad de información oportuna, complejidad de la aplicación, grado de confianza para
decisiones importantes, la cantidad de tiempo que se utilizará la aplicación y el número de personas que
lo usará. La evaluación de riesgos define qué aspectos de una aplicación particular serán cubiertos por
la auditoría. El alcance de la auditoría puede variar según los riesgos identificados.
Plan de auditoria
El plan de auditoría detalla los pasos y procedimientos para cumplir con los objetivos de la auditoría. Como en cualquier aud
La auditoría de los sistemas de aplicación comienza con un análisis preliminar del entorno de control mediante
revisar los estándares, políticas y procedimientos existentes. Durante la auditoría, estas normas, políticas,
y los procedimientos deben evaluarse para verificar su integridad y eficiencia operativa. El preliminar
El análisis debe identificar la estrategia de la organización y las responsabilidades de gestión y control.
aplicaciones de curricán. Documentar la comprensión del sistema de solicitud también es imprescindible en
este escenario.
El plan de auditoría documentará además los procedimientos necesarios para llevar a cabo el examen.
para garantizar que el sistema de aplicación esté diseñado e implementado de manera efectiva, así como también funcione
coherente con las políticas y procedimientos de la organización. Procedimientos realizados por auditores de TI
debe proporcionar una seguridad razonable de que las aplicaciones se han diseñado e implementado adecuadamente
mentado, y:
◾ Cumplir con los estándares, políticas y procedimientos

◾ Logre operaciones eficientes y económicas
◾ Cumplir con los requisitos legales
◾ Incluya los controles necesarios para proteger contra pérdidas o errores graves
◾ Proporcionar controles y pistas de auditoría necesarios para la administración, el auditor y para la revisión operativa.
propósitos
Publicación especial 800-53A del NIST, revisión 4, Evaluación de los controles de seguridad y privacidad
en Organizaciones y Sistemas de Información Federal (2014), proporciona una evaluación integral
Página 287
procedimientos para examinar los controles de seguridad y privacidad en los sistemas y organizaciones de información feder
zations. * Es importante tener en cuenta que estos procedimientos también se aplican a los sistemas de solicitud no federales.
Comunicación
La primera área a comunicar es el alcance de participación del auditor de TI. Es muy importante
asegurarse de que se comprendan y comuniquen las expectativas de la gerencia sobre el papel del auditor de TI
nicado a todos los participantes. Los auditores de TI deben desarrollar una línea abierta de comunicación con ambos
gestión y usuarios. Si no existe una buena relación entre estos grupos, la información
puede ser retenido del auditor de TI. Aunque el auditor de TI debe cultivar un buen trabajo
relaciones con todos los grupos con responsabilidades de diseño, el auditor de TI debe permanecer independiente.
A lo largo de la auditoría, el auditor de TI hará recomendaciones de control resultantes de
hallazgos identificados. Dependiendo de la cultura de la organización, estas recomendaciones pueden necesitar
ser manejado de manera informal con cada propietario de la aplicación a cargo del área o proceso deficiente, o
formalmente presentándolos al comité directivo. En cualquier caso, el auditor de TI siempre debe
considere el valor de la recomendación de control versus el costo de implementar el control.
Las recomendaciones deben ser específicas. Deben identificar el problema y no el síntoma,
y permitir que se implementen y prueben los controles adecuados. Hallazgos, riesgos como resultado de esos
Los hallazgos y las recomendaciones de auditoría generalmente se documentan en una carta formal (es decir,
Letra). Consulte el Anexo 3.9 del Capítulo 3 para ver un ejemplo del formato de una Carta de administración.
de una auditoría de TI.
Conclusión
Las aplicaciones son fundamentales para que las organizaciones realicen sus negocios. Representan un significado
inversión importante para muchas organizaciones, ya que proporcionan funciones automatizadas para respaldar eficazmente
el proceso empresarial. Las aplicaciones también presentan riesgos para las organizaciones. Estos riesgos deben ser
abordados con una adecuada selección e implementación de controles de aplicación.
EUD implica el uso de aplicaciones desarrolladas por el departamento, como hojas de cálculo y
bases de datos, que se utilizan con frecuencia como herramientas en la realización del trabajo diario. Estas hojas de cálculo y
Las bases de datos son esencialmente una extensión del entorno de TI y la salida generada a partir de ellas puede
utilizarse en la toma de decisiones comerciales que afecten a la empresa. El nivel de riesgo y el requerido
Los controles a implementar dependen de la criticidad de la aplicación de la DUE.
Los auditores, la gerencia, los desarrolladores y los consultores de seguridad deben estar al tanto del negocio.
ness riesgos asociados con los sistemas que intercambian información comercial electrónica. Tal electronica
intercambio de documentos comerciales entre socios comerciales (o comerciales) utilizando un estándar
El formato se conoce como EDI. Ejemplos comunes de información comercial intercambiada a través de
EDI incluye facturas y órdenes de compra, y riesgos como la pérdida de continuidad del negocio, aumentaron
dependencia de los sistemas, pérdida de confidencialidad de información sensible y mayor exposición a
los fraudes son algunos de muchos. Algunas normas que proporcionan una base para las evaluaciones de auditoría de EDI in
ASC X12 de ANSI (Norteamérica) y EDIFACT (Internacional).
El uso de aplicaciones web se ha convertido en la clave de orientación para muchas empresas. Las empresas pueden
utilizar aplicaciones web con fines de marketing y otras para reemplazar a su cliente tradicional
aplicaciones de servidor. Las aplicaciones web incluyen el uso de un navegador web en el lado del cliente que es
Página 288
generalmente es independiente de la plataforma y requiere menos potencia informática. Algunos beneficios de la aplicación
ciones incluyen reducción del tiempo de comercialización, mayor satisfacción del usuario y reducción de gastos relacionado
mantenimiento y soportes. Las aplicaciones web también están sujetas a riesgos similares a los tradicionales
aplicaciones a las que están expuestos los sistemas.
Debido a estos riesgos, se deben implementar controles para garantizar que las aplicaciones continúen
satisfacer las necesidades del negocio de forma eficaz y eficiente. Los controles de aplicación son específicos y
exclusivo de las aplicaciones. Se preocupan por la exactitud, integridad, validez y autoría
rización de los datos capturados, ingresados, procesados, almacenados, transmitidos y reportados. Solicitud
los controles se dividen en controles de entrada, procesamiento y salida.
Los auditores de TI pueden ayudar a las organizaciones revisando sus sistemas de aplicaciones para asegurarse de que
cumplir con la estrategia y los estándares de la organización, así como proporcionar funciones automatizadas para
Apoyar eficazmente el proceso empresarial. Las aplicaciones deberán evaluarse el riesgo para determinar el
nivel de participación de la auditoría. Los resultados de la evaluación de riesgos también indican la cantidad de tiempo neces
Es necesario asignar a la aplicación particular, los recursos necesarios, etc. Preparación de un plan de auditoría
a continuación, se describen los objetivos y procedimientos de auditoría a realizar. Por último, auditores de TI
comunicar los hallazgos identificados a lo largo de la auditoría y las recomendaciones a la gerencia.
1. Explique por qué el acceso remoto no autorizado representa un riesgo para las aplicaciones.
2. Explique cómo el procesamiento incompleto, duplicado e inoportuno puede afectar negativamente a las solicitudes.
3. Enumere siete riesgos comunes asociados con los sistemas de aplicación de DUE.
4. ¿Cómo pueden las aplicaciones DUE convertirse en sistemas incompatibles?
5. En el entorno actual, la amenaza de los virus informáticos es alta debido a la cantidad ilimitada
número de fuentes desde las que se pueden introducir. Los virus informáticos se pueden copiar
de un disco, descargado de una página web infectada, diseminado entre los equipos conectados
dentro de una red, etc. Describa los riesgos o problemas que pueden resultar de los virus informáticos.
6. Explique qué significa EDI. Describa las posibles implicaciones derivadas de los riesgos relacionados con
sistemas de aplicación que intercambian información comercial electrónica.
7. Enumere y explique cinco principios y prácticas de codificación segura de acuerdo con OWASP para Web.
aplicaciones.
8. Los controles de aplicación pueden describirse como técnicas utilizadas para controlar la entrada, el procesamiento,
y salida de información en una aplicación. ¿A qué se refieren los controles de entrada ? Describa resumidamente
qué controles de entrada aseguran.
9. Los controles de aplicación pueden describirse como técnicas utilizadas para controlar la entrada, el procesamiento,
y salida de información en una aplicación. ¿A qué se refieren los controles de procesamiento ? Brevemente
describir lo que garantizan los controles de procesamiento.
10. Los controles de aplicación se pueden describir como técnicas utilizadas para controlar la entrada, el proceso
ing y salida de información en una aplicación. ¿A qué se refieren los controles de salida ? Brevemente
describir lo que garantizan los controles de salida.
Ejercicios
1. Una empresa permite que los pedidos se realicen directamente a través de su sitio web. Describe los tres
los riesgos más importantes del sistema de aplicaciones que podrían contribuir al acceso no autorizado a un
información del pedido del cliente. Identificar los controles que se deben implementar para mitigar esos riesgos.
Página 289

2. Un departamento
Describa los dos de nómina
riesgos mástiene una aplicación
destacados de hoja
del sistema de tiempo donde
de aplicaciones y los los empleados
controles ingresan sus horas trabajada
que ayudarían
mitigar esos riesgos.
3. Los departamentos dentro de una empresa tienen su propia persona de soporte técnico que crea y
mantiene las aplicaciones. Describe tres riesgos asociados con esta práctica. Que controla
¿Recomendaría ayudar a minimizar esos riesgos?
4. Explique la importancia de los controles de aplicación y proporcione ejemplos sobre cómo se utilizan.
para salvaguardar la entrada, el procesamiento y la salida de información.
CASO: APLICACIONES DE DUE
INSTRUCCIONES: Una empresa utiliza aplicaciones EUD, en particular, una hoja de cálculo para mantener
mantener su presupuesto. La hoja de cálculo se utiliza para solicitar el presupuesto de cada uno de los
departamentos. Posteriormente, el departamento de presupuesto compila las hojas de cálculo individuales
en una hoja maestra, revisa y revisa el presupuesto en función de sus limitaciones y luego lo usa
para cargar los valores presupuestarios en el sistema financiero de la empresa, donde el departamento puede
ver su presupuesto finalizado.
TAREA: Enumere y describa al menos siete riesgos de aplicación destacados asociados con el uso
de un sistema de hoja de cálculo. También debe explicar cómo cada uno de los riesgos que enumera
puede afectar el sistema de hojas de cálculo. Busque más allá del capítulo para obtener ejemplos específicos,
literatura y / o cualquier otra fuente externa válida para respaldar su respuesta. Envíe una palabra
archivo con una portada, respuestas a la tarea anterior y una sección de referencia al final. los
El archivo enviado debe tener entre 5 y 7 páginas (interlineado doble), incluida la portada.
página y referencias. Esté preparado para presentar su trabajo a la clase.
CASO — CONTROLES DE ENTRADA
INSTRUCCIONES: Una empresa tiene un sistema contable centralizado. Cada individuo

El departamento compila actualmente sus transacciones contables en papel de su contabilidad local.
sistema. Para eliminar el papel y aumentar la eficiencia, el Gerente de Auditoría de la empresa
Acabo de pedirle a usted, auditor de TI, que le ayude a elaborar un plan para implementar una interfaz de
el sistema de contabilidad de cada departamento individual al sistema de contabilidad centralizado.
TAREA: Preparar una nota para el Gerente de Auditoría nombrando y describiendo los aspectos más críticos.
controles que recomendaría en este caso particular. Debes buscar
más allá del capítulo (es decir, literatura de TI y / o cualquier otra fuente externa válida) para apoyar
tu respuesta. Incluya ejemplos, según corresponda, para evidenciar su caso. Envíe una palabra
archivo con una portada, respuestas a la tarea anterior y una sección de referencia al final. los
El archivo enviado debe tener 5 páginas (doble espacio entre líneas), incluida la portada y la referencia.
ences. Esté preparado para presentar su trabajo a la clase.
Otras lecturas
1. Una encuesta de conceptos y cuestiones clave para el mantenimiento de registros electrónicos. (2003). Intercambio electrónico d
www.ctg.albany.edu/publications/reports/key_concepts?chapter=3&PrintVersion=2
Página 290

2. Baker, S., Waterman, S. e Ivanov, G. (2010). En el fuego cruzado: infraestructura crítica en la era de
Guerra cibernética , McAfee.
edu / secure-coding-practice-Guidelines (consultado en julio de 2017).
4. Oficina Federal de Investigaciones (FBI), Informe de crímenes financieros al público en los años fiscales 2007
hasta 2011 , Departamento de Justicia, Estados Unidos. www.fbi.gov/stats-services/publications/
informe-delitos-financieros-2010-2011
5. Guía de auditoría de tecnología global (GTAG) 8: Controles de aplicaciones de auditoría . El Instituto de Interna
Auditores. https://na.theiia.org/standards-guidance/recommended-guidance/practice-guides/Pages/
GTAG8.aspx (consultado en julio de 2017).
6. GS1 EDI. GS1. www.gs1.org/edi (consultado en julio de 2017).
7. ISACA. (2017). COBIT y controles de aplicaciones: una guía de gestión , www.isaca.org/knowledge-
center / research / researchdeliverables / pages / cobit-and-application-controls-a-management-guide.aspx
8. ISACA. (2017). Seguridad de las aplicaciones web: consideraciones comerciales y de riesgo , www.isaca.org
9. Jones, DC, Kalmi, P. y Kauhanen, A. (2011). Efectos sobre la empresa y los empleados de una información empresarial
Sistema de información: Evidencia microeconométrica. En t. J. Prod. Econ. , 130 (2), 159-168.
10. Predicciones de amenazas de McAfee Labs 2017, informe publicado en noviembre de 2016. www.mcafee.com/au/
recursos / informes / rp-amenazas-predicciones-2017.pdf
11. Informe de amenazas de McAfee Labs: diciembre de 2016 www.mcafee.com/ca/resources/reports/rp-quarterly-
amenazas-dec-2016.pdf
12. Morella, R. (agosto de 2015). Auditoría de aplicaciones web. Estrategias de auditoría de TI para aplicaciones web. ISACA
Semana Friki. www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2015/081115-10AM-
WebAppSecurity.pdf
13. Instituto Nacional de Estándares y Tecnología. Publicación especial 800-53A, Revisión 4, Evaluación
controles de seguridad y privacidad en los sistemas y organizaciones de información federales, diciembre de 2014.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
14. Odette. Conceptos básicos de EDI. www.edibasics.com/edi-resources/document-standards/odette/ (consultado en julio
2017).
6 (3), 841–849.
evaluación de control para organizaciones, IEEE Conference on Open Systems. 21-24 de octubre de 2012, Kuala
Lumpur, Malasia.
19. OWASP. (2013). OWASP top 10-2013: Los 10 riesgos de seguridad de aplicaciones web más críticos. www.
owasp.org/index.php/Top_10_2013-Risk
20. OWASP. Prácticas de codificación seguras: guía de referencia rápida. www.owasp.org/index.php/OWASP_
Secure_Coding_Practices _-_ Quick_Reference_Guide (consultado en junio de 2017).
21. Romney, MB y Steinbart, PJ (2015). Sistemas de información contable , 13ª edición. Pearson
Educación, Reading, Reino Unido.
edu / secure-coding-practice-Guidelines (consultado en junio de 2017).
24. Tradacoms. Conceptos básicos de EDI. www.edibasics.co.uk/edi-resources/document-standards/tradacoms/ (consultado
Julio de 2017).
Página 291
Capítulo 10
Gestión de control de cambios
1. Describa la importancia de un sistema de control de cambios.
2. Explique el proceso de gestión del control de cambios.
3. Analice los procedimientos de gestión del control de cambios.
4. Definir la gestión de la configuración y describir las actividades de muestra realizadas como parte de un
plan de gestión de la configuración.
5. Describa la gestión del cambio organizacional.
6. Describa la participación de la auditoría en un examen de control de cambios.
La gestión del control de cambios es el proceso que asegura la implementación efectiva de cambios en
un entorno de TI. El propósito de la gestión del control de cambios es minimizar la probabilidad de
interrupciones y cambios no aprobados, así como errores. Un proceso de gestión de control de cambios
listas de análisis, revisión, aprobación e implementación de cambios. Desde una perspectiva de TI, cambie
La gestión del control se concibe en términos de cambios realizados en los sistemas de TI existentes. Sin embargo,
Los cambios que afectan a la organización también son un factor. En muchos casos, los cambios organizacionales son la
los que introducen cambios en los sistemas de TI.
Este capítulo describe la gestión del control de cambios, en términos de TI y organizativos.
cambio. La gestión del control de cambios de TI es una de las áreas de control más importantes para garantizar
la integridad, disponibilidad, confiabilidad, seguridad, confidencialidad y precisión de una organización o
Sistema de TI de apoyo a la organización. La gestión del control de cambios es también uno de los tres principales
Controles informáticos generales que evalúan las políticas y procedimientos de la organización, relacionados con la aplicació
sistemas, con el fin de apoyar el funcionamiento eficaz de los controles de aplicaciones. Ejemplos de general
los controles dentro de la gestión de control de cambios pueden incluir aprobaciones de solicitudes de cambio; solicitud
y actualizaciones de bases de datos; y supervisión, seguridad y gestión de cambios de la infraestructura de red.
El cambio organizacional también merece consideración, debido a su impacto potencial en la organización.
ción y el aumento de las relaciones con los cambios en el entorno de TI. El cambio organizacional es
impactado por las limitaciones introducidas por la tecnología y la cultura de la organización. Debates de investigación
si la tecnología es un producto de la cultura o si las prácticas de la organización son dictadas
por tecnología. Independientemente, es seguro decir que son interdependientes. En consecuencia, la discusión
de la gestión del cambio se ha ampliado para incluir también los cambios relacionados con la organización.
265
Página 292

Importancia de un sistema de control de cambios
El software de aplicación está diseñado para admitir una función específica, como el proceso de nómina o préstamo.
En g. Normalmente, varias aplicaciones pueden operar bajo una instancia de software del sistema operativo.
El establecimiento de controles sobre la modificación de los programas de software de aplicación ayuda a garantizar que
sólo se implementan programas autorizados y modificaciones autorizadas. Instituir políticas,
Los procedimientos y técnicas ayudan a garantizar que todos los programas y modificaciones de programas se realicen corre
autorizado, probado y aprobado. Tales políticas, procedimientos y técnicas también aseguran que el acceso
a la distribución de los programas se controla cuidadosamente. Sin los controles adecuados, existe el riesgo
que las funciones de seguridad podrían omitirse o "desactivarse" inadvertidamente o deliberadamente. Tal falta de
Los controles también podrían aumentar el riesgo de introducir irregularidades en el procesamiento o código malicioso. por
ejemplo:
◾ Un programador experimentado podría modificar en secreto el código del programa para proporcionar un medio de
eludir los controles para obtener acceso a datos confidenciales.
◾ Se podría implementar la versión incorrecta de un programa, perpetuando así la obsolescencia o
procesamiento erróneo que se supone que ha sido actualizado.
◾ Se podría introducir un virus, inadvertidamente o intencionalmente, que interrumpa el procesamiento.
El enfoque principal de un sistema de control de cambios es controlar los cambios que se realizan en el software.
sistemas en funcionamiento, ya que los sistemas operativos producen los estados financieros y la mayoría de los
Se realizan cambios de gramo para mantener los sistemas operativos. Sin embargo, los mismos riesgos y mitigación
Los controles se aplican a los cambios asociados con los sistemas en desarrollo, una vez que tanto la gestión de usuarios
y el equipo de desarrollo del proyecto ha aprobado formalmente sus requisitos básicos.
Un sistema de control de cambios de TI garantiza que exista una separación adecuada de funciones entre los
inicia el cambio, quién aprueba el cambio y quién implementa el cambio en una producción
medio ambiente .
Proceso de gestión de control de cambios

El área de control más importante en cualquier entorno de procesamiento de información es la gestión
mención de cambios en los sistemas existentes. Dada la complejidad del hardware, software y aplicaciones
relaciones en el entorno operativo, cada cambio debe definirse, planificarse, coordinarse adecuadamente
dinado, probado e implementado.
Un proceso de gestión de control de cambios eficaz reduce el riesgo de interrupción de los servicios de TI.
Una vez que se ha propuesto un cambio, debe evaluarse el riesgo y el impacto. Si un cambio propuesto
introduce un riesgo significativo para el entorno operativo, todas las partes afectadas deben ser notificadas,
el nivel apropiado de administración debe aprobar el programa de implementación y retirarse
Se deben desarrollar planes para eliminar el cambio del sistema si es necesario. El cambio propuesto
primero debe ser revisado por el personal de gestión del cambio para identificar posibles conflictos con otros
sistemas. El proceso de gestión del control de cambios debe revisarse periódicamente para evaluar
su eficacia. Una gestión de control de cambios bien definida, estructurada y bien implementada
El proceso beneficia a las organizaciones al:
◾ Reducir las interrupciones del sistema que pueden provocar pérdidas comerciales
◾ Minimizar la cantidad de retrocesos causados por una implementación de cambios ineficaz
Página 293
Gestión del control de cambios ◾ 267

◾ Proporcionar una implementación de cambios consistente que permita a la gerencia asignar personal y
tiempo del sistema de manera eficiente y cumplir con las fechas de implementación programadas
◾ Proporcionar documentación precisa y oportuna para minimizar el impacto en los cambios relacionados
problemas
Se pueden introducir cambios para corregir un error o agregar una nueva funcionalidad. También se pueden introducir camb
de nuevas versiones de software y la distribución de nuevo software. Además, pueden producirse cambios
desde la gestión de la configuración y el rediseño del proceso empresarial. Las grandes empresas tienden a emplear
herramientas automatizadas para ayudar a garantizar una gestión de cambios eficaz.
Hay tres tipos de cambios: rutinarios, no rutinarios y de emergencia. Cambios de rutina
normalmente tienen un impacto mínimo en las operaciones diarias. Pueden implementarse o retirarse
rápida y fácilmente. Los cambios no rutinarios tienen potencialmente un mayor impacto en las operaciones. Ellos
afectan a muchos usuarios y con frecuencia tienen una implementación prolongada y compleja y un procedimiento de
duras. Un cambio de emergencia es cualquier cambio, mayor o menor, que debe realizarse rápidamente, sin
siguiendo los procedimientos estándar de control de cambios. La gerencia debe aprobar dichos cambios antes
se realizan o implementan. Un proceso de gestión de control de cambios generalmente cubre el
siguiendo:
◾ Formulario de solicitud de cambio

◾ Evaluación de impacto
◾ Controles
◾ Cambios de emergencia
◾ Cambiar documentación
◾ Cambios de mantenimiento
◾ Versiones de software
◾ Distribución de software
Formulario de solicitud de cambio

Un formulario de solicitud de cambio garantiza que solo se implementen los cambios autorizados. Requiere que un
Se mantiene un registro de todos los cambios en el sistema, se asignan los recursos adecuados y se
priorizado. Los cambios deben priorizarse en términos de beneficio, urgencia y esfuerzo requerido, así como
como posible impacto en las operaciones existentes. El formulario también debe gestionar la coordinación entre
cambios para tener en cuenta las interdependencias que puedan existir. Los procedimientos de solicitud de cambio deben
estar documentado y requerir:
◾ Registro de solicitudes de cambio que se mantendrá para cada sistema

◾ Definición de la autoridad y responsabilidad del departamento de TI, así como del usuario.
◾ Aprobación por la gerencia después de que se revisa toda la información relacionada
◾ Un cronograma de cambios, que también permite cambios fuera del cronograma (por ejemplo,
cambios geniales, etc.)
◾ Aprobación de la gerencia para todos los cambios realizados fuera del cronograma
◾ Un proceso de notificación para que los solicitantes estén informados sobre el estado de su
peticiones
La figura 10.1 ilustra un ejemplo de un formulario de solicitud de cambio estándar.
Página 294

Figura 10.1 Ejemplo de un formulario de solicitud de cambio estándar
Formulario de solicitud de cambio Versión: 1.0

Número de formulario: XYZ-WI-CCM-002 Fecha de vigencia: XX / XX / 20XX
Departamento: Tecnología de la información Fecha de revisión: XX / XX / 20XX
SOLICITUD DE CAMBIO
Nombre y teléfono:
Departamento:
Fecha de solicitud:
Finalización prevista
Fecha:
Descripción de
Cambio y motivos:
Departamento (s) afectado (s):
Firma:
CAMBIAR INFORMACIÓN
Número de solicitud de cambio:
Clasificación: Cambio planeado: ______ Cambio de emergencia: ______
(Marque con una "X") Cambio de mantenimiento: ______ Cambio de configuración: ______
Tipo: Solicitud: ______ Base de datos: ______
(Marque con una "X") Sistema operativo: ______ Red: ______
Otra especificar: ______
Requisitos:
Evaluación de impacto:
Plan de respaldo / respaldo
Procedimientos:
GERENTE DE UNIDAD DE NEGOCIO
Nombre y teléfono:
Procedimientos de revisión
Realizado:
Aprobación para comenzar
Trabajando con el cambio:
PROCEDIMIENTOS DE PRUEBA REALIZADOS Y RESULTADOS
APROBACIONES FINALES
Nombre Firma Fecha
Pruebas de aceptación del usuario
Revisión de gestión
Planificación,
Implementación en
Producción y
Notificación a los usuarios
Actualización de documentación
Página 295

Evaluación de impacto
Cada cambio requiere una evaluación de impacto para garantizar que las posibles consecuencias negativas (resultado
de la implementación del cambio) se identifican y planifican. Los cambios pueden introducir
duce riesgos para la disponibilidad, integridad, confidencialidad y rendimiento de un sistema. Cada cambio
la solicitud debe incluir evidencia de respaldo de la evaluación de impacto del cambio. El análisis de impacto
sis debe incluir medidas específicas en comparación con los límites prescritos. Esto permite la extensión de la
impacto a evaluar. Los cambios también deben revisarse para determinar el efecto sobre el cumplimiento
con las políticas, los procedimientos y los procesos existentes.
Control S
Se necesitan controles a través de procesos y herramientas automatizadas para garantizar la integración de las solicitudes de
cambios de software y distribución de software. Esta integración también es consistente con los requisitos
Mentos de la Ley Sarbanes-Oxley de 2002, que se relacionan con informes financieros, en particular datos
integridad, integridad y seguimiento. Los controles de cambio también garantizan que no solo los autorizados
se realizaron cambios, sino también la detección de cambios no autorizados, la reducción de los errores debidos a
cambios en el sistema y un aumento en la confiabilidad de los cambios. Ejemplos de controles sobre el cambio
El proceso de control incluye verificaciones independientes del éxito o fracaso de los cambios implementados.
así como actualizar la infraestructura o configuración del sistema para detectar cambios no autorizados.
Otros controles relevantes para evaluar el proceso de control de cambios incluyen asegurar que:
◾ La gerencia evalúa los riesgos comerciales y el impacto de los cambios propuestos en el sistema.
antes de la implementación en entornos de producción. Los resultados de la evaluación se utilizan cuando
diseñar, dotar de personal y programar la implementación de cambios para minimizar las interrupciones
operaciones.
◾ Se documentan las solicitudes de cambios en el sistema (por ejemplo, actualizaciones, arreglos, cambios de emergenci
y aprobado por la dirección antes de realizar cualquier trabajo relacionado con el cambio.
◾ La documentación relacionada con la implementación del cambio es adecuada y completa.
◾ La documentación de cambios incluye la fecha y hora en las que los cambios fueron (o serán)
instalado.
◾ Se ha publicado y comunicado la documentación relacionada con la implementación del cambio
a los usuarios del sistema.
◾ Los cambios del sistema se prueban antes de la implementación en el entorno de producción de manera consistente
con planes de prueba y casos.
◾ Planes de prueba y casos que involucren datos de prueba completos y representativos (en lugar de
datos) son aprobados por los propietarios de la aplicación y la gestión de desarrollo.
Los controles adicionales sobre el proceso de control de cambios se muestran en el Apéndice 3 del Capítulo 3.
El apéndice enumera los controles aplicables a la mayoría de las organizaciones y considerados como procedimientos rector
tanto para la gestión de TI como para los auditores de TI.
Otras fuentes de controles relacionados con la gestión del cambio son ofrecidas por el conocido ISO /
IEC 20000, COBIT y los marcos ITIL. El propósito del servicio de TI ISO / IEC 20000
estándar de gestión es asegurar que todos los cambios en el hardware, equipos de comunicaciones y
El software, así como el software del sistema, se evalúan, aprueban, instalan y monitorean en un
de manera eficaz, eficiente y controlada. COBIT 5 define un conjunto de habilitadores o procesos para
ayudar a lograr los objetivos de la organización. Los habilitadores específicos para la gestión del cambio son parte
Página 296

de uno de los dominios principales de COBIT 5: Construir, Adquirir e Implementar (BAI). Ejemplos de estos
son BAI05 Gestionar la habilitación de cambios organizativos, BAI06 Gestionar cambios y BAI07
Gestionar la aceptación de cambios y la transición. Estos habilitadores (procesos o controles) ayudan a la organización
nizaciones para asegurar la implementación efectiva de cambios en el entorno de TI (es decir, minimizar
la probabilidad de interrupciones y cambios no aprobados, así como errores). ITIL proporciona un conjunto de mejores
prácticas para priorizar e implementar cambios en el entorno de TI de una manera eficaz y eficiente
manera, sin afectar negativamente a los clientes o los niveles de servicio acordados. Es decir, el ITIL
Las prácticas de gestión del cambio garantizan que se utilicen métodos y procedimientos adecuados cuando
implementar cambios minimizando la posibilidad de interrupción de los servicios actuales. Muchos
Las organizaciones complementan las mejores prácticas de ITIL con sus propios controles, políticas y / o procedimientos.
Cambios de emergencia
Los cambios de emergencia son cambios que se requieren fuera del horario prescrito. Normalmente,
Se requieren cambios de emergencia para corregir errores en la funcionalidad que afectan adversamente el desempeño del si
mance o procesos de negocio. Es posible que también se requieran cambios de emergencia para corregir los descubrimientos
vulnerabilidades a la disponibilidad, integridad o confidencialidad. Por el contrario, los cambios de emergencia deben
no comprometer la integridad, disponibilidad, confiabilidad, seguridad, confidencialidad o exactitud de la
sistema. Debido a las consecuencias que pueden ocurrir con los cambios de emergencia, solo deben
implementado en emergencias declaradas.
Los procedimientos de cambio de emergencia no solo deben describir el proceso de implementación
cambios de emergencia, pero también debe incluir una descripción de lo que constituye un cambio de emergencia.
Los parámetros y características definitivos de un cambio de emergencia deben describirse claramente.
Los cambios de emergencia deben documentarse como cambios regulares, pero la documentación puede no
ocurrir hasta después de que se realice el cambio debido a la naturaleza de la emergencia. Estos cambios requieren
autorización formal de los responsables del sistema y de la dirección antes de la implementación
ción. En algunos casos, las copias de seguridad antes y después del cambio se conservan para una revisión posterior.
Los cambios de emergencia, por su naturaleza, plantean un mayor riesgo, ya que pasan por alto algunos de los
análisis y procesos del proceso tradicional de control de cambios. Como resultado, las auditorías de cambio
Los procedimientos de control deben prestar especial atención a los cambios de emergencia.
Cambiar la documentación
En la mayoría de los casos, los cambios en los entornos de producción requerirán que la documentación y
los procedimientos se actualicen para reflejar la naturaleza del cambio. La documentación actual garantiza la
mantenimiento del sistema por parte de cualquier miembro del personal asignado y minimiza la dependencia de
personal.
Los procedimientos de control de cambios deben incluir una tarea para actualizar la documentación,
procedimientos, recursos de la mesa de ayuda y materiales de capacitación. Los cambios en los procesos comerciales tambié
ser considerado. La documentación, los procedimientos y los procesos comerciales deberían recibir la
la misma consideración y prueba que otros componentes afectados por el cambio.
Cambios de mantenimiento
Las actualizaciones de mantenimiento también se consideran cambios y deben contabilizarse y autorizarse en
los procedimientos de control de cambios. Las tareas de mantenimiento deben describirse con el nivel de detalle necesario.
sario para asegurar controles apropiados. Las acciones de mantenimiento deben registrarse y el registro revisado para
Página 297

asegurar la idoneidad. Los controles de acceso deben usarse para limitar las acciones del personal
haciendo el mantenimiento solo al acceso requerido. Un ejemplo de una tarea de mantenimiento de rutina es
desfragmentar un disco duro para eliminar archivos fragmentados o clústeres perdidos.
Versiones de software
Como cualquier cambio, las nuevas versiones de software requieren la aprobación de la gerencia para garantizar que el camb
autorizado, probado y documentado antes de que la nueva versión de software se implemente en el producto
entorno de Los siguientes controles abordan la implementación de nuevas versiones de software:
◾ Deben realizarse copias de seguridad adecuadas de los datos y programas del sistema antes del cambio.
◾ El control de versiones debe tenerse en cuenta en el proceso. Un ejemplo de control de versiones
system (VCS) se llama git. Git es una herramienta VCS de código abierto y gratuita diseñada para rastrear modificaci
ficaciones en archivos informáticos. Git también coordina el trabajo en dichos archivos modificados entre múltiples
personas, y lo hace de manera eficaz y eficiente.
◾ Las versiones de software solo deben considerarse recibidas del repositorio central prescrito.
◾ También se requiere un proceso formal de traspaso para que el personal autorizado participe en la
proceso, el software implementado no cambia de lo que se probó, y los medios de software
es preparado por la función apropiada basada en las instrucciones formales de construcción.
distribución de software
El propósito de la distribución de software es garantizar que todas las copias del software se distribuyan en
de acuerdo con sus acuerdos de licencia. La distribución de software minimiza el riesgo de múltiples
versiones del software que se están instalando al mismo tiempo. Varias versiones de un paquete de software
aumentar los costos de soporte ya que los usuarios y el personal de soporte deben estar capacitados y capacitados en las func
funcionalidad y problemas con cada versión.
La distribución de software también debe tener en cuenta una verificación de la integridad del software, así como
verificación del cumplimiento de los acuerdos de licencia de software. Los acuerdos de licencia normalmente otorgan
permiso para utilizar el software especificado en función de las limitaciones, el número de usuarios, la ubicación, el tipo de
usar, y así sucesivamente. Las licencias de software pueden ser para uso ilimitado por una persona específicamente nombrad
uso actual por un número ilimitado de usuarios simultáneos, una licencia de sitio para uso ilimitado en uno
sitio, o una licencia empresarial para uso ilimitado por la empresa.
La violación de los acuerdos de software tiene ramificaciones legales para las empresas, incluidos los costos de
copias instaladas sin licencia, daños y honorarios legales, y pérdida de reputación corporativa. Noticias sto-
Las preocupaciones sobre la piratería de software se centran principalmente en casos judiciales relacionados con la creación
distribuir software ilegalmente. Sin embargo, las historias no impresas son las que se resolvieron extrajudicialmente con
empresas. La Asociación de la Industria de Software e Información (SIIA) es una organización compuesta
de empresas de la industria del software y la información. Uno de sus objetivos es proteger la
propiedad intelectual de sus miembros. SIIA es fundamental para influir en las leyes para proteger la inteligencia
propiedad intelectual y la adopción de medidas para combatir la piratería de software. Programa Corporativo Antipiratería d
identifica, investiga y resuelve casos de piratería de software en nombre de sus miembros. Software dis-
Las prácticas de distribución deben incluir los siguientes controles:
◾ La distribución se realiza de manera oportuna solo a los autorizados.

◾ Existe un medio para garantizar la verificación de la integridad, y esto se incorpora a la
instalación.
Página 298

◾ Existe un registro formal de quién ha recibido el software y dónde se ha implementado. Esta
El registro también debe coincidir con el número de licencias adquiridas.
Procedimientos de gestión de control de cambios

Los procedimientos de gestión del control de cambios garantizan que todos los miembros de una organización estén siguiend
el mismo proceso para iniciar, aprobar e implementar cambios en sistemas y aplicaciones.
Las siguientes son áreas a considerar al desarrollar procedimientos de gestión de control de cambios.
Objetivos
Los objetivos potenciales para los procedimientos de gestión del control de cambios incluyen:
◾ Documente el (los) motivo (s) del cambio

◾ Identificar al personal que solicita el cambio
◾ Formalice quién hará el cambio
◾ Definir cómo se realizará el cambio
◾ Evaluar el riesgo de falla y el impacto del cambio
◾ Documentar planes de respaldo y procedimientos de respaldo en caso de que surja la necesidad
◾ Ayuda a comunicarse con los afectados por el cambio.
◾ Identificar las consideraciones de recuperación ante desastres
◾ Identificar conflictos entre múltiples cambios
◾ Mejorar la conciencia de la dirección sobre el proceso de gestión del cambio.
Alcance
El alcance de los procedimientos de gestión del control de cambios puede incluir:
◾ Hardware
◾ Software del sistema operativo
◾ Instancias de base de datos
◾ Software de aplicación
◾ Herramientas de terceros
◾ Telecomunicaciones
◾ Cortafuegos
◾ Red (por ejemplo, red de área local, red de área amplia, enrutadores, servidores, etc.)
◾ Entorno de las instalaciones (p. Ej., Suministro de energía ininterrumpida, eléctrico, etc.)
Consejos o Comités de Gestión de Control de Cambios

Los Consejos o Comités de Gestión de Control de Cambios son entidades comunes para tratar con
nating la comunicación de cambios dentro de una organización. A continuación se presentan posibles fuentes de
miembros de una junta o comité de gestión de control de cambios:
◾ Equipos de desarrollo / soporte de aplicaciones (por ejemplo, finanzas, recursos humanos, etc.) que pueden
proporcionar pistas
Página 299

◾ Operaciones del centro de datos
◾ Redes / telecomunicaciones
◾ Mesa de ayuda
◾ Representantes de usuarios clave
Las personas de la junta o comité de gestión de control de cambios deben seleccionarse

en su perspectiva profunda y amplio conocimiento de las áreas que representan, así como su
conciencia de otras áreas funcionales involucradas. El objetivo es garantizar que las decisiones tomadas sean
objetivo ya que estos cambios tienen el potencial de afectar a toda la organización. Cambio de control
Las juntas o comités de administración deben reunirse diaria o semanalmente. Los siguientes tipos de cambios
a menudo se consideran durante las reuniones diarias de revisión de cambios:
◾ Lanzamientos de emergencia y arreglos normalmente relacionados con circunstancias en las que la producción
abajo
◾ Clones, restauraciones, enlaces o nuevas instancias de bases de datos
◾ Solicitudes "aceleradas" de nuevas funciones que no pueden esperar a las
fechas para actualizaciones
◾ Mantenimiento de aplicaciones o sistemas
◾ Actualizaciones a herramientas de desarrollo
Los siguientes temas a menudo se tratan durante las reuniones semanales de revisión de cambios:
◾ Migraciones de nuevos lanzamientos

◾ Actualizaciones a herramientas de producción o desarrollo
◾ Configuración del entorno para migraciones o herramientas
◾ Actualizaciones de terceros
◾ Cambios de configuración
◾ Cambios de hardware
Criterios para aprobar cambios

La aprobación de cambios puede basarse en los siguientes criterios:
◾ Estado del entorno de producción. Antes de determinar si se debe aprobar un cambio,

La junta o comité de gestión de control de cambios debe evaluar el desempeño y
disponibilidad de cada sistema en el entorno de producción durante la semana anterior. En gen-
En general, si el entorno de producción ha funcionado bien y ha estado disponible para los usuarios,
es más probable que la junta o comité de gestión de control de cambios apruebe los cambios que
proporcionar nuevas funciones o cambios que puedan tener un mayor riesgo de fallas. Por el contrario,
si el estado del entorno de producción durante la semana anterior ha sido malo, el
Es más probable que la junta o comité de cambios apruebe solo aquellos cambios diseñados para corregir
problemas.
◾ Cambiar de nivel. Como parte del proceso de aprobación, el nivel de cambio se examina junto con el
información e instrucciones detalladas adjuntas a la solicitud de cambio. Los adjuntos
debe detallar el riesgo asociado y el impacto del cambio. Particularmente importantes son
los comentarios subjetivos proporcionados por el solicitante del cambio indicando las razones de la
Página 300

nivel de cambio asignado. El nivel de cambio puede basarse en seis factores: riesgo, impacto, comunicación
requisitos de cation, tiempo de instalación, requisitos de documentación y educación o capacitación
requisitos.
◾ Efecto acumulativo de todos los cambios propuestos. El consejo de administración de control de cambios o el
mittee es un lugar donde se juntan todos los cambios solicitados. La junta o el comité
El participante tiene la capacidad de examinar varios cambios, cada uno de los cuales puede parecer tener un
riesgo razonable si se toma de forma independiente, pero cuando se consideran todos los cambios propuestos
como grupo, el efecto compuesto puede resultar en demasiada actividad de cambio, por lo tanto, riesgo.
Cuando la junta o comité llega a esta conclusión, su responsabilidad es priorizar
los distintos cambios, aprobar los más significativos y recomendar que los demás
ser reprogramado.
◾ Disponibilidad de recursos. La junta o comité de gestión de control de cambios evalúa la
disponibilidad de personas, tiempo y recursos del sistema al considerar la programación y
aprobación de cambios.
◾ Criticidad. Hay problemas que pueden afectar el impacto del cambio tal como lo ve el
solicitante. Por ejemplo, el solicitante del cambio puede sentir que el impacto es relativamente bajo
porque su cambio afecta a un pequeño porcentaje de la comunidad de usuarios. sin embargo, el
junta o comité puede considerar que la criticidad es alta porque ese pequeño porcentaje de
users es un cliente o usuario crítico. Un ejemplo podría ser el departamento de finanzas durante una
proceso de cierre de fin de año.
Post-implementación
Después de la implementación de un cambio, las evaluaciones de si los procedimientos de cambio fueron
seguidos y cumplidos sus objetivos deben ser realizados. Las evaluaciones posteriores a la implementación deben
también considere si la implementación y los planes de retroceso o los procedimientos de retroceso fueron adecuados
y el estado final del cambio (es decir, completo, incompleto, en curso, fallido o cancelado).
Puntos de origen e inicio del cambio

Los procedimientos de gestión de control de cambios deben identificar a los usuarios o grupos de usuarios que inician
cambios. Los proveedores, operadores de computadoras, programadores de aplicaciones o sistemas, o usuarios finales son lo
los que normalmente solicitan cambios. Además, los procedimientos deben garantizar que todas las solicitudes sean
enviado mediante un formulario de solicitud de cambio estándar que contiene información, como:
◾ Fecha de solicitud
◾ Nombre del solicitante
◾ Descripción y motivos del cambio
◾ Áreas que pueden verse afectadas por el cambio
◾ Aprobaciones para trabajar con el cambio y para su implementación en el entorno de producción
Se debe determinar la urgencia de cada solicitud y todos los cambios solicitados deben ser presentados por
prioridad y fecha. Los procedimientos también deben proporcionar los medios para implementar cambios de emergencia.
en respuesta a un problema operativo. Los puntos de control para el procesamiento de cambios de emergencia deben
establecido para registrar, documentar y obtener la aprobación posterior de los cambios. Cambios de emergencia
deben tener referencias cruzadas con los informes de problemas de operaciones para ayudar a verificar el registro y
manejo de los cambios.
Página 301

Cada solicitud de cambio debe numerarse secuencialmente y registrarse en un registro de cambios en una
punto de control. La mayoría de las organizaciones utilizan herramientas en línea para facilitar este proceso. La solicitud de
ingresado en línea y, según las áreas afectadas, enviado electrónicamente a esas áreas para su aprobación. los
La aprobación del área responsable también se registra en línea. Todas y cada una de las discusiones sobre ese cambio
están documentados en línea. Una vez programado el cambio, el sistema en línea notificará a los usuarios
del próximo cambio; también proporcionará una confirmación una vez que se haya producido el cambio. Almacenamiento
Esta información en línea permite a la gerencia realizar una revisión posterior de todos los cambios para un
Variedad de razones. Uno puede ser la ocurrencia rutinaria del mismo tipo de emergencia, indicando
que los cambios están solucionando el síntoma y no el problema subyacente. Además, la gerencia podría
Analizar qué cantidades de sus recursos se dedican a la rutina, no rutinaria y de emergencia.
cambios. Si una aplicación requiere una cantidad significativa de recursos para realizar cambios, esto puede ser
un indicador de que la aplicación está llegando al punto en el que reemplazarla puede ser más rentable.
Puntos de aprobación
Los puntos de aprobación deben programarse durante todo el proceso de control de cambios. Todas las personas clave y
los departamentos afectados por un cambio deben ser notificados de su programa de implementación. Los que
puede requerir notificación incluyen:
◾ Usuarios finales del sistema

◾ Proveedores
◾ Programadores de aplicaciones
◾ Gestión de TI
◾ Personal de operaciones
◾ Personal de control de datos
◾ Gestión de red
◾ Auditores
◾ Proveedores de servicios de terceros
Una parte importante del proceso de aprobación que a menudo se pasa por alto son las pruebas. Idealmente, las pruebas ocur
en un espejo del sistema de producción (es decir, entorno de prueba). Los cambios del sistema deben probarse para
asegúrese de que no afecten negativamente a las aplicaciones. Los cambios de aplicación se pueden agrupar
en cambios de sistema o funcionalidad. Los cambios del sistema normalmente no afectan al usuario final y
generalmente mejoran la velocidad de procesamiento de transacciones. El grupo de apoyo a la programación, en cambio
de los usuarios finales, generalmente prueba estos cambios. Los cambios de funcionalidad son obvios para el usuario final
y deben ser probados y aprobados por ellos. Los cambios de funcionalidad deben verificarse en una prueba
medio ambiente. El entorno de prueba es un espejo del entorno de producción, que incluye el
datos, programas u objetos. Los archivos de datos deben expandirse para incluir inusuales o no rutinarios
transacciones para garantizar que se utilicen todos los tipos de transacciones en la prueba.
Los niveles de aprobación deben estar predeterminados en cuanto a quién puede aprobar qué cambios. Parte de
El proceso de control de cambios debe asegurar que se obtenga el nivel de aprobación apropiado antes de cualquier
los cambios se trasladan a la producción.
Cambiar la documentación
A medida que un sistema envejece, la tarea de realizar un seguimiento de los cambios y su impacto en el funcionamiento
El sistema, el entorno de operaciones y los programas de aplicación se vuelven cada vez más difíciles. los
Página 302

La organización debe mantener un registro de todos los cambios realizados en el sistema. Sin tal
registro, es imposible determinar cómo los cambios propuestos afectarán al sistema. No solo debería
el cambio debe documentarse con el formulario de solicitud de cambio, pero también en la documentación del programador
tación. La documentación del programador es absolutamente necesaria para el mantenimiento futuro.
También es importante saber cuándo y por qué se solicitaron cambios pero no se implementaron.
Con los cambios de personal, es posible que esté revisando un tema que ya se considera que no merece tiempo.
pero debe revisarse para garantizar su integridad. Lo contrario también puede ser cierto cuando un
El problema del servicio podría tener mérito debido al entorno empresarial cambiante.
Puntos de revisión
Los procedimientos de gestión de control de cambios deben coordinarse y revisarse cuidadosamente si se producen cambios
al sistema se implementarán con éxito. Los siguientes pasos deben incluirse en el
proceso de revisión de cambios:
◾ Los cambios pendientes se revisan con personal clave en operaciones, programación de aplicaciones,
control de redes y datos, y auditoría.
◾ Se envía notificación de cambio por escrito a todas las partes interesadas, informándoles de la naturaleza
del cambio, programación del cambio, propósito del cambio, individuo responsable de
implementar el cambio y los sistemas afectados por el cambio.
◾ Se proporciona suficiente tiempo de respuesta para que las partes interesadas examinen los cambios propuestos. los
La notificación de cambio debe indicar la fecha límite de respuesta y la persona a contactar para
Información Adicional.
◾ Se deben realizar reuniones periódicas de control de cambios (por ejemplo, diarias, semanales, mensuales, etc.) para di
cambios con personal clave.
◾ Se archivan informes sobre los cambios implementados para registrar los resultados posteriores a la implementación y
éxitos y problemas.
El proceso y los procedimientos de gestión del control de cambios deben documentarse en forma de
política organizacional. El Apéndice 6 ilustra un ejemplo de una gestión de control de cambios estándar.
política de ment.
Gestión de la con guración

La gestión de la configuración controla el inventario físico y las relaciones entre los componentes.
componentes que forman un conjunto de objetos de "línea base" que están sujetos a cambios. El Instituto Nacional de
Estándares y Tecnología definieron el proceso de gestión de configuración de software (SCM) en
su Publicación 500-223, “Un marco para el desarrollo y la garantía de alta integridad
Software." Los principales objetivos del proceso SCM son rastrear las diferentes versiones del
software y asegúrese de que cada versión del software contenga las salidas de software exactas generadas
ated y aprobado para esa versión. Debe establecerse antes de que comience el desarrollo de software y
continuar durante todo el ciclo de vida del software. SCM es responsable de garantizar que cualquier cambio
al software durante los procesos de desarrollo se realizan de forma controlada y completa.
El proceso de SCM produce un plan de gestión de la configuración del software. A continuación se enumeran ejemplos
actividades dentro de dicho plan SCM.
Página 303
1. Identificación de elementos de configuración de software (CI)

- Seleccionar las funciones más importantes y críticas que requerirán atención constante y
control durante todo el desarrollo de software. Estos se convertirán en los IC.
- Asignar un identificador / número único a cada CI.
- Establecer líneas de base para los IC, es decir, documentos que han sido revisados formalmente.
y acordados, que (1) sirven como base para un mayor desarrollo y (2) pueden ser
cambiado solo a través de procedimientos formales de control de cambios. Se establecerán líneas de base
incluir:
• Línea de base funcional (la finalización y aceptación de los requisitos del sistema
especificación): requisito previo para el desarrollo de la especificación de requisitos de software
ficación (SRS) para cada CI.
• Línea de base asignada (la revisión y aceptación de los SRS): el prerrequisito de la
desarrollo de la descripción del diseño del software para todos los componentes que componen un CI.
• Configuración de desarrollo (línea de base "rodante" controlada por el desarrollador): todos los documentos
mentos y código aceptado y comprometido para el control de configuración hasta el establecimiento
Realización de la línea base del producto.
• Línea de base del producto (establecida con la conclusión exitosa de una configuración
auditoría): requisito previo para el funcionamiento y mantenimiento del software.
2. Informe de problemas, seguimiento y acción correctiva: documente cuándo se desarrolla un software
La actividad de mejora no cumple con su plan, la deficiencia de producción o el comportamiento anómalo y
dar la acción correctiva tomada.
3. Control de cambios: documente, evalúe, resuelva y apruebe cambios en el software.
4. Revisión de cambios: evalúe los problemas y cambios, implemente los cambios aprobados y proporcione
retroalimentación a los procesos afectados por los cambios.
5. Análisis de trazabilidad: rastree hacia adelante y hacia atrás a través de las salidas de software actuales
para establecer el alcance del software afectado.
6. Control de configuración: autoridad delegada para controlar los cambios en el software; determinar
método para procesar solicitudes de cambio.
7. Contabilidad del estado de configuración: mantenga registros que detallen el estado del producto de software.
el desarrollo de uct, por ejemplo, registrar los cambios realizados en el software, el estado de los documentos,
cambios en el proceso, historial de cambios, estado de lanzamiento, etc.
8. Revisiones y auditorías de configuración: audite los CI antes del lanzamiento de la línea base del producto o la actuali
versión de la línea de base del producto; revisión para determinar el progreso y la calidad del producto. Dos tipos
de las auditorías incluyen:
- Auditoría de configuración funcional; prueba que el desempeño real de un CI está de acuerdo con su
requisitos de software establecidos en el SRS.
- Auditoría de configuración física; asegura que la documentación que se entregará con el
software representa el contenido del producto de software.
9. Archivar, recuperar y liberar: archivar las salidas de software (con copias de seguridad) para que
no se puede cambiar sin la debida autorización y se puede recuperar si es necesario.
El software que se lanza debe describirse y autorizarse.
Gestión de cambios organizacionales

La gestión del cambio organizacional se relaciona con la capacidad y los métodos de la organización para adoptar,
gestionar y adaptarse al cambio. Los factores para evaluar el cambio varían según el alcance de la
Página 304
cambio (es decir, cambios en los hábitos de trabajo en contraposición a cambios en la propia organización). A pesar de
cómo se gestiona la TI, las organizaciones aún la promulgan para obtener los resultados monetarios esperados.
En consecuencia, un proyecto de TI en realidad puede considerarse un producto de la cultura de la organización.
Hay muchos estudios que apoyan la afirmación de que muchos proyectos de TI fallan debido a la incapacidad
de la organización para adaptarse al cambio necesario para aprovechar las TI. Las organizaciones encuentran
Es difícil cambiar sus prácticas y estructuras, especialmente si la aplicación se percibe como
en conflicto con la cultura de la empresa.
Definición de cultura organizacional

La cultura organizacional se compone de estructuras de incentivos, política, apoyo a la interacción
relaciones organizacionales y repercusiones sociales.
Los incentivos ofrecidos por la organización pueden afectar el éxito de la organización en la adaptación
cambiar porque los usuarios no necesariamente ven las ventajas "naturales" de adoptar el cambio. Como
Como punto de precaución, los incentivos no deben entrar en conflicto con otras recompensas o incentivos o con la cultura.
Por ejemplo, si a los empleados se les dice que se les ofrecerá capacitación para aprender un nuevo estado de la técnica
sistema, pero correrán el riesgo de perder su bonificación debido a su aumento en el tiempo no facturable, el empleado
verá el entrenamiento como un castigo en lugar de ser considerado un incentivo.
La política de la empresa puede tener efectos significativos en el éxito de un nuevo sistema o cambio de TI.
en la organización. La mayoría de los modelos de cambio organizacional excluyen el reconocimiento de la importancia
tancia de las influencias políticas sobre el cambio organizacional. Por ejemplo, un nuevo sistema de TI puede cambiar
el poder de la información. En un caso, proporcionó a la oficina corporativa acceso directo en línea al
actividad comercial en vivo en cada oficina comercial. Antes del nuevo sistema, las oficinas sobre el terreno pudieron determ
mía cómo y cuándo presentar sus cifras de ventas a la oficina corporativa. En algunos casos, las ventas
Office modificaría los datos de ventas reales con ventas que aún no se realizaron. Esto habilitó las ventas
oficinas para presentar sus “mejores” cifras de ventas. Con acceso directo a la información de ventas, la empresa
Rate Office tuvo la facultad de ver los datos cuando y cómo quisieran, lo que les permitió conocer
la volatilidad de las ventas de una oficina determinada. Porque transfirió el control sobre la información a
las oficinas corporativas, se percibió que el sistema transfiere el poder de decisión a la oficina corporativa
lejos de las oficinas de ventas. Posteriormente se produjeron luchas de poder entre las oficinas de ventas y el
oficina corporativa.
El soporte técnico y organizativo es fundamental para el uso eficaz de la TI. Una infraestructura de apoyo
La estructura incluye prácticas organizacionales, personal de apoyo clave y acceso a técnicos y
conjuntos de habilidades nacionales. En este modelo, el aprendizaje individual y organizacional se considera un subconjunto
el sistema de TI. Muchas de las principales implementaciones de sistemas de TI ahora incluyen la revisión de procesos come
sesiones dentro de su alcance de implementación. Esto permite a la organización revisar su negocio.
proceso en términos del cambio que se introducirá en el sistema. Este análisis de fit-gap identifica
Elimina brechas en la funcionalidad, que es parte integral de los procesos comerciales. Se pueden hacer planes posteriores
para adaptarse a estas brechas en el proceso comercial rediseñado, cambios en los servicios comerciales o
modificaciones al sistema en sí.
Las relaciones interorganizacionales y las redes sociales son apoyadas e impactadas a través de
el uso de TI. Se cree que la influencia de las relaciones y las redes sociales explica por qué algunos
las tecnologías son compatibles y otras no. Observando comunidades en línea y electrónicas
mercados: ¿es la influencia de la tecnología en las relaciones y las redes que crearon en línea
comunidades y mercados electrónicos o viceversa?
Un ejemplo de una comunidad en línea exitosa es eBay. Su comunidad está compuesta por indi-
compradores y vendedores individuales, así como empresas grandes y pequeñas. Se apoyan las relaciones con los miembros
Página 305
con foros de discusión. El sentido de comunidad se utiliza para garantizar que se sigan las directrices de eBay.
con una filosofía de “vigilancia del vecindario”.
Gestionar el cambio organizacional

El cambio de cultura y estructura debe gestionarse a lo largo del ciclo de vida. Incluye personas,
organización y cultura. Una cultura que comparte valores y está abierta al cambio contribuye al éxito
impuesto. Para facilitar el proceso de cambio, los usuarios deben participar en el diseño y la implementación.
del proceso empresarial y del sistema. Un plan de comunicación y formación y profesional
los planes de desarrollo también apoyan esto.
Los procesos comerciales asociados con una implementación de software deben estar alineados. En
adaptar paquetes de software, las organizaciones se enfrentan a la pregunta de si deben
organización al software o viceversa. Para minimizar el mantenimiento del software, el
pany debe considerar cambiar el proceso comercial para que se ajuste al software y el software debe ser
modificado lo menos posible. Reducir la personalización reduce los errores y mejora la capacidad de
utilizar versiones más recientes.
El cambio organizacional se basa en una comunicación eficaz. Las expectativas deben ser cumplidas
municado. La comunicación, la educación y las expectativas deben gestionarse a lo largo del
organización. Las aportaciones de los usuarios también deben gestionarse para garantizar que los requisitos, comentarios,
y se obtienen la aprobación. La comunicación incluye la promoción formal de la implementación
cambio, así como el progreso de la organización en la adopción del cambio. Los empleados también deben
Conozca el alcance, los objetivos, las actividades y las actualizaciones y la expectativa de cambio con anticipación.
Los planes de formación y desarrollo profesional deben incorporarse a cualquier esfuerzo para
introducir cambios en una organización. Los empleados deben estar capacitados en los nuevos procesos.
y procedimientos. Además, el equipo asignado para implementar el cambio requiere
formación en el proceso y procedimientos. La formación para adaptarse al cambio también es beneficiosa para todos
empleados.
Participación en la auditoría
Una auditoría o examen de control de cambios determinaría si los cambios del sistema están autorizados,
probado, documentado, comunicado y controlado. Por lo general, se cubren las siguientes áreas:
◾ Autorización
◾ Pruebas (unidad, sistema y aceptación del usuario)
◾ Documentación
◾ Comunicación
◾ Controles
Como se ve, la gestión del control de cambios es un proceso que tiene un impacto en la producción-procesamiento
medio ambiente. Esto incluye cambios de hardware, software de aplicación y redes. Con
con respecto a la revisión de la gestión de cambios de la aplicación, se define la gestión de control de cambios
como cualquier modificación a los programas que pueda afectar el proceso de producción. Procesamiento de producción
incluye disponibilidad, confiabilidad e integridad del sistema. Muchas organizaciones han migrado desde
un entorno dominado por mainframe a un entorno heterogéneo con mainframe, cliente /
servidor y miniordenadores, entre otros. Estos sistemas requieren procedimientos, herramientas,
y conjuntos de habilidades para gestionar el cambio.
Página 306
A medida que las organizaciones continúan evolucionando, su entorno de control sobre el proceso de cambio puede
también aumentan el riesgo de que la producción se vea afectada negativamente. Control de cambios insuficiente
Los procesos pueden tener los siguientes riesgos:
◾ Los sistemas de TI existentes (por ejemplo, aplicaciones, bases de datos, sistemas operativos, redes, etc.) que
no satisfacen las necesidades de procesamiento de información de la organización, lo que resulta en
datos inexactos o inválidos.
◾ Los sistemas de informes financieros no pueden transferir datos entre otros sistemas de TI y
sus componentes de infraestructura subyacentes (por ejemplo, dispositivos de red, hardware de servidor).
◾ Desarrollo e implementación inapropiados de sistemas de TI que pueden resultar en errores
cálculos, procesamiento no confiable, registro incompleto de transacciones y otros
incorrecciones, entre otros.
◾ Los procedimientos inadecuados para definir bases de datos de manera adecuada pueden resultar en que los sistemas d
de procesar datos precisos.
◾ Los procedimientos inapropiados para implementar bases de datos de manera efectiva pueden resultar en
no disponible y / o de difícil acceso.
◾ Pérdida de datos o interrupciones del sistema como resultado de errores, omisiones o intenciones maliciosas.
◾ Fraude o abuso de los sistemas y / o datos de la empresa como resultado de cambios no autorizados.
El objetivo de una auditoría de gestión de control de cambios es asegurar que los cambios implementados en
Los sistemas de producción y las aplicaciones no afectan negativamente el sistema, la aplicación o la disponibilidad de datos
capacidad o integridad. Con ese fin, los auditores deben verificar que todos los cambios realizados en la producción
los sistemas y aplicaciones están debidamente autorizados y documentados. Un factor crítico de éxito
porque la gestión del control de cambios es la cultura de la organización. ¿Entiende la gerencia
el papel crítico de la gestión del control de cambios, y reconoce el impacto del control de cambios
la gestión tiene sobre el éxito de la organización? ¿Son políticas de gestión de control de cambios,
procedimientos y procesos implementados en entornos cliente / servidor, mainframe y escritorio, para
¿ejemplo? ¿Existen controles para garantizar que los cambios realizados para no impactar negativamente en la estabilidad de
integridad o integridad de los datos? La auditoría debe incluir procedimientos tales como:
◾ Obtener copias de políticas y / o procedimientos relacionados con la gestión del control de cambios.
◾ Entrevistar al personal de soporte de la aplicación para determinar los procedimientos formales, informales y de emerg
duros utilizados para implementar cambios en los sistemas de producción y aplicaciones.
◾ Obtener copias de los formularios y registros de solicitudes de control de cambios.
◾ Seleccionar una muestra de cambios de los cambios registrados y determinar el cumplimiento de
políticas, procedimientos y mejores prácticas.
◾ Obtener copias de los registros de llamadas de la mesa de ayuda para determinar los impactos adversos de los cambios
◾ Determinar si el software nuevo y los cambios en el software existente se realizan de manera adecuada y formal.
autorizado por el gerente apropiado.
◾ Determinar que todos los nuevos software y cambios de software se prueban correctamente, utilizando archivos de pru
y directorios, antes de que se muevan a producción.
◾ Determinando que todos los resultados de las pruebas son efectivos y revisados por alguien que no sea el
autor.
◾ Determinar que los nombres de archivos y programas se controlan adecuadamente para evitar duplicados
nombres.
◾ Determinar que toda la documentación de respaldo se actualiza antes de una solicitud o un cambio
a una aplicación se pone en producción.
Página 307
◾ Determinar que las aplicaciones de producción se almacenan en un directorio protegido contra

cambios autorizados.
◾ Determinar los medios para realizar un seguimiento de los cambios en las aplicaciones de producción. ¿Hay una salida
sistema de registro para evitar cambios no autorizados?
El Apéndice 3 (discutido en el Capítulo 3) proporciona un programa de auditoría de TI de muestra para el control de cambio
área de TI de control general de gestión, que incluye una lista completa de los objetivos de control de auditoría y
actividades que se deben seguir y realizar al realizar un examen de gestión de control de cambios
nación. Dependiendo del tamaño y complejidad de la organización, estos objetivos de control y
Es posible que sea necesario revisar o ampliar las actividades para obtener una cobertura de auditoría adecuada del cambio.
función de gestión de control.
El auditor obtiene los antecedentes necesarios, determina los controles clave,
forma pruebas sustantivas limitadas para evaluar la confiabilidad y efectividad de los controles del proceso,
y evalúa el proceso. El auditor debe tomarse el tiempo para familiarizarse completamente con y
comprender el proceso de control de cambios. Él o ella debe desarrollar un diagrama de flujo que documente
proceso en el que puntos de origen e inicio, puntos de aprobación, cambios en la documentación,
y todos los puntos de revisión están identificados. Además, los diagramas de flujo desarrollados por los auditores deben docu
procedimientos para cambios de emergencia y que no son de emergencia. La figura 10.2 ilustra un examen de diagrama de f
de un proceso de gestión de control de cambios llevado a cabo en una organización. Note las diferentes
roles involucrados en el proceso (p. ej., Solicitante de cambios, Gerente de proyecto, Junta de control de cambios,
etc.), y las diversas actividades que realizan.
Solicitante de cambio Gerente de proyecto Tablero de control de cambios Equipo de implementación
Del solicitante El cambio es

CRF CRF
programado y
probado
Identifica
Reseñas
necesitar & Reseñas
Y
prepara CRF
aprueba
CRF
CRF Exitoso
resultados de la prueba
CRF si
Aprobar
Registros CRF?
si si No
CRF y
¿Factible? pistas
estado Implementación
No
de cambio
Cambio
No se ha enviado
De vuelta por
CRF repitiendo
Cierra
CRF
norte Al solicitante
Figura 10.2 Diagrama de flujo que muestra un proceso de gestión de control de cambios estándar.
Página 308
Conclusión
Los cambios en los sistemas son frecuentes y se pueden introducir para corregir errores e implementar nuevas funciones.
y versiones de software, o desde la gestión de la configuración y los rediseños de los procesos de negocio. Un cambio
El proceso de gestión de control es, por tanto, uno de los controles más importantes que se deben tener. Un
El proceso de gestión de control de cambios eficaz reduce el riesgo de interrupción de los servicios de TI. El PRO-
El proceso también garantiza la integridad, disponibilidad, confiabilidad, seguridad, confidencialidad y precisión de un
organización o sistema de TI de apoyo a la organización. Además, el proceso no solo supervisa todos
cambios realizados en los sistemas, pero asegura una adecuada segregación de funciones entre quién inicia la
cambio, quién aprueba el cambio y quién implementa el cambio en el entorno de producción.
Para respaldar el proceso y garantizar que se lleve a cabo de manera eficaz, los programas de gestión de control de camb
se ponen en marcha cedimientos. Los procedimientos de gestión de control de cambios garantizan que todos los miembros
de la organización seguir un proceso estándar para iniciar, aprobar e implementar cambios
a sistemas y aplicaciones.
Las organizaciones también deben implementar buenas prácticas de gestión de la configuración.
La gestión de la configuración se refiere al proceso utilizado para supervisar la instalación de actualizaciones en
hardware del sistema, software del sistema operativo y firmware para garantizar que el hardware y el software
funcionan como se esperaba y que se mantiene un registro histórico de cambios.
La gestión del cambio organizacional también merece consideración debido a su impacto potencial
sobre la organización y el aumento de las relaciones con los cambios en el entorno de TI.
El cambio organizacional se ve afectado por las limitaciones introducidas por la tecnología y la organización.
cultura de la La cultura de una organización se compone de sus estructuras de incentivos, política y
relaciones con otras organizaciones y la comunidad.
Una auditoría o examen de control de cambios determina si los cambios del sistema están autorizados,
probado, documentado, comunicado y controlado. El objetivo de una gestión de control de cambios
auditoría de ment es para asegurar que los cambios implementados en los sistemas de producción y aplicaciones no
afectar negativamente la disponibilidad o integridad del sistema, la aplicación o los datos. Con ese fin, los auditores deben
Verificar que todos los cambios realizados en los sistemas de producción y las aplicaciones estén debidamente autorizados.
rizado y documentado.
1. La implementación de políticas, procedimientos y técnicas ayuda a realizar cambios y modificaciones
que los sistemas (por ejemplo, programas, aplicaciones, etc.) estén debidamente autorizados, probados, aprobados y
distribuidos o controlados cuidadosamente. Sin controles adecuados como el anterior, hay una
riesgo de que cambios o modificaciones no autorizados puedan introducir irregularidades en el procesamiento
o código malicioso, entre muchos otros. Enumere ejemplos de otros riesgos que podrían
impactar la seguridad de los sistemas.
2. Explicar los beneficios para las organizaciones de implementar un cambio bien definido y estructurado.
proceso de gestión de control.
3. Analice los tres tipos de cambios que se implementan típicamente en sistemas y aplicaciones.
4. Nombre y describa cuatro riesgos asociados con el proceso de lanzamiento de software.
5. Describa los controles que normalmente se incluyen al seguir las buenas prácticas de distribución de software.
6. Nombre y resuma los cinco criterios para aprobar cambios.
7. Una vez aprobados, los cambios deben programarse para su implementación. En este punto, todas las claves
Las personas y departamentos afectados por un cambio deben ser notificados de la próxima implementación.
tación. Enumere aquellos que pueden requerir dicha notificación.
Página 309
8. Resuma cómo el Instituto Nacional de Estándares y Tecnología define el proceso de

gestión de configuración de software.
9. Describir las interdependencias entre la gestión del cambio de TI y el cambio organizacional.
administración.
10. ¿Cuál es el objetivo de una auditoría de gestión de control de cambios? Enumere al menos siete procedimientos
en una auditoría de gestión de control de cambios.
Ejercicios
1. Discuta qué son los cambios de emergencia y por qué requieren atención "especial" de
administración.
2. Analice por qué la revisión de la documentación es una parte importante de la gestión del cambio.
3. Explique el propósito de un formulario de solicitud de cambio. ¿Por qué deberían ser
documentado?
4. Con un navegador web de Internet, busque y examine dos recientes (en los últimos 5 años)
situaciones en las que la implementación de cambios y / o modificaciones a las finanzas existentes
los sistemas de aplicación han fallado. Su tarea: resumir por qué fallaron tales implementaciones.
Luego, identifique soluciones o controles que, si se implementaron, pueden haber evitado estos fallos.
implementaciones. Respalde sus razones y justificaciones con literatura de TI y / o cualquier otra
fuente externa válida. Incluya ejemplos según corresponda para evidenciar su caso. Presentar una
Word con una portada, respuestas a las tareas anteriores y una sección de referencia al final.
El archivo enviado debe tener entre 6 y 8 páginas (interlineado doble), incluyendo
portada y referencias. Esté preparado para presentar su trabajo a la clase.
5. Siguiendo su recomendación, su organización acaba de crear un Control de cambios
Junta directiva o comité (Junta) para supervisar el cambio implementado recientemente
proceso de gestión de control. Como Presidente de la Junta, prepare (utilizando un memorando para-
mat) un documento para discutir y presentar a todos los miembros durante la primera reunión de la Junta. los
El documento debe incluir: (1) descripción de las responsabilidades de la Junta recién formada
y (2) los tipos de cambios y / o temas que serán considerados y discutidos durante la
reuniones.
CASO: AUDITORÍA DE GESTIÓN DE CONTROL DE CAMBIOS
NARRATIVA: AMBIENTE DE TI Y CONTROL DE CAMBIOS

PROCESO DE GESTIÓN
La auditoría de TI del cliente ABC Company es para el año fiscal que finalizó el 31/12/20XX. En varios
planificando reuniones con el cliente / personal de la entidad, reunió la siguiente información
pertenecientes a las aplicaciones financieras relevantes del cliente. Estas son las aplicaciones que
forman el alcance de la auditoría de este año:
1. SAP: maneja todas las transacciones de contabilidad y libro mayor. El servidor de SAP es
SapAppServ1, y su versión de sistema operativo (o / s) es UNIX AIX VX. SAP está clasificado
como un software comprado que requiere una personalización significativa. La base de datos que apoya
SAP es Oracle, con el nombre de servidor SapDbServ1.
Página 310
2. Sistema Bill-Inv: maneja la facturación y la gestión de inventario. El servidor del sistema Bill-Inv
es InfAppServ1, y su versión o / s es OS 400 VX. Bill-Inv System es un software comprado
con poca personalización. La base de datos es IBM DB2, con el nombre de servidor InfDbServ1.
3. APS2: maneja todas las transacciones de tesorería e inversiones. El servidor que aloja el
La aplicación es Aps2AppServ1, y su versión o / s es OS400 VX. APS2 es un comprado
software que requiere una personalización significativa. La base de datos es Oracle, con nombre de servidor
Aps2DbServ1.
4. Sistema heredado: maneja transacciones relacionadas con los activos fijos de la entidad. El legado
El servidor del sistema es LSAppServ1 y su versión de sistema operativo es Windows VX. El sistema heredado
está clasificado como un software desarrollado internamente. La base de datos es propietaria, con servidor
nombre LSDbServ1.
5. Kronos: maneja las transacciones de tiempo y asistencia de los empleados. El servidor de Kronos es
KAppServ1, y su versión o / s es Linux VX. Kronos también está clasificado como un
software desarrollado. La base de datos es propietaria, con el nombre de servidor KDbServ1.
6. HR & P: maneja transacciones relacionadas con recursos humanos y procesamiento de nóminas y
desembolso. Esta aplicación se subcontrata a una organización de servicios llamada ADP.
Los s que alojan las aplicaciones son los que alojan las bases de datos. Todo lo anterior relevante
las aplicaciones, a excepción de RR.HH.&P, se encuentran en las instalaciones de la sede de la entidad,
habitación, primer piso, en Melbourne, FL. HR&P está subcontratado, lo que significa que la aplicación, su
base de datos y o / s, así como todos los servidores relacionados se encuentran fuera de las instalaciones del cliente. por
descripción de los procesos y procedimientos relacionados con esta aplicación subcontratada, consulte
el informe de la organización de servicios del auditor.
Durante el año fiscal, no se realizaron modificaciones significativas para el Bill-Inv
Aplicaciones relevantes de System, Legacy System, Kronos y HR&P. SAP y APS2, sin embargo,
se actualizaron significativamente a sus versiones actuales el 1 de marzo y el 15 de noviembre,
respectivamente.
Cliente ABC Company tiene tres departamentos relacionados con TI, todos reportando al Director de TI.
El director de TI depende directamente del director financiero de la entidad. Los departamentos de TI
y su personal de apoyo se enumeran a continuación:
◾ Infraestructura y operaciones (I&O): Gerente de I&O, supervisor de la mesa de ayuda, capacitador y

Soporte al usuario final y administrador de red / LAN
◾ Programas y soporte de sistemas de aplicaciones (ASP & S) —ASP & S Manager, Software
Programador, analista programador y administrador de SAP
◾ Soporte de bases de datos y sistemas operativos (D & OSS): especialista en soporte de bases de datos
y especialista en soporte de sistemas operativos
Aplicaciones compradas (SAP, Bill-Inv System y APS2)

El proceso del cliente para la selección y compra de nuevas aplicaciones se realiza tomando
en consideración del impacto económico y operativo. Siempre que la necesidad de adquirir
Se identifica el software de gestión, tanto el personal de gestión como los representantes del usuario final.
comunidad (usuarios) establecen requisitos de diseño y compatibilidades para el futuro
aplicación adquirida. Según el Director de TI y el Gerente de I&O, una vez que se necesita
se ha identificado y se han establecido los requisitos, personal de gestión de TI
Página 311
son responsables de evaluar al menos tres alternativas considerando la relación costo-beneficio

buques y el impacto en el entorno de TI. Una vez evaluada, una alternativa es preliminar
seleccionados y discutidos con los gerentes comerciales para asegurar la alineación entre la información
sistemas e iniciativas empresariales. Solicitudes que superen los $ 100,000 y / o que tengan el potencial
Los riesgos de TI que impactan están sujetos a evaluaciones de riesgos y análisis de impacto empresarial. Sobre
finalización de tales análisis, la alternativa seleccionada (respaldada con documentación de análisis
ción) se envía al Director de Finanzas para su aprobación final. Una vez que una selección de
se realiza la aplicación, el personal de TI realiza copias de seguridad completas de la aplicación anterior. Personal de TI
luego prepare un entorno separado para que los usuarios comiencen a probar si la nueva aplicación
se ejecuta como se esperaba y si los datos son precisos. También comparan la nueva aplicación
contra la aplicación anterior (es decir, pruebas en paralelo). Una vez realizada la prueba, los usuarios proporcionan
tancia y soporte para la instalación de la nueva aplicación en el entorno de producción.
El personal de TI es responsable de informar a todos los usuarios afectados sobre las fechas de instalación. los
lo anterior es parte de la política de la entidad para seleccionar y comprar nuevas aplicaciones; sin embargo,
dicha política no ha sido revisada y / o actualizada durante los últimos 5 años. Una política debe
ser revisado y actualizado al menos una vez al año para reflejar cambios en el procesamiento de la entidad
medio ambiente.
Todos los cambios o actualizaciones de las aplicaciones compradas son realizados por el proveedor de la aplicación.
personal y devuelto a la entidad para su instalación. Según ASP & S Manager, cambios o
las actualizaciones recibidas de los proveedores actualmente no se rastrean ni registran. El cliente reconoce
Edge hay herramientas y técnicas disponibles basadas en la Web que pueden rastrear o registrar este tipo de
cambios, pero sienten que sus costos pueden no estar justificados. Debido a que estos cambios o actualizaciones son de
proveedor, la entidad confía en que han sido probados adecuadamente (en el sitio del proveedor) antes
el vendedor los reenvía al cliente. Por tanto, la entidad no realiza un back-
ups de la aplicación existente antes de la implementación de los cambios o actualizaciones. ESO
el personal instala los cambios / actualizaciones recibidos en un entorno de prueba separado. Las pruebas son
realizado a fondo para asegurar que los nuevos cambios sean consistentes y se ajusten a la
Alquiler de necesidades comerciales. Los resultados de la prueba, si tienen éxito, se comunican verbalmente al gerente en
cargar. Además de la aprobación del personal de TI, no se requieren aprobaciones adicionales
antes de la implementación de los cambios / actualización a producción. El personal de TI es responsable
para informar a todos los usuarios afectados sobre las fechas de instalación en el entorno de producción. Lo anterior
Los procedimientos se han formalizado en una política. La política se actualiza anualmente.
Una vez que se realiza la implementación de cambios o actualizaciones a las aplicaciones compradas,
El personal de TI, liderado por ASP&S Manager, realiza diversas pruebas para validar la integridad,
exactitud e integridad de la información.
Aplicaciones desarrolladas internamente (sistema heredado y Kronos)

Como se discutió con ambos, I&O Manager y ASP&S Manager, el proceso de desarrollo
la implementación de aplicaciones internas o la implementación de cambios en las aplicaciones internas es un estándar
y proceso común. El proceso puede resultar de (1) los usuarios que identifican las necesidades del sistema;
(2) errores identificados y que requieren corrección; y / o (3) aplicaciones mismas que obligan
implementación de nuevos parches / actualizaciones. Solicitudes de desarrollo de aplicaciones internas
o implementar sus cambios son enviados por usuarios que completan un "Sistema
Formulario de solicitud de modificación ”(SMRF). El SMRF es una herramienta basada en web que la entidad utiliza par
rastrear y controlar solicitudes, e incluye información, como el nombre de la aplicación
Página 312
o sistema, nombre del solicitante, fecha, departamento (s) afectados y una descripción de la solicitud
cambio. Además, la herramienta proporciona información sobre el programador que trabajará
con el cambio y la fecha estimada de finalización. Una vez que se completa el SMRF y
Se establecen los requisitos, el ASP & S Manager evalúa el impacto del cambio. Si
la aplicación interna o el cambio se considera significativo, se considera un proyecto y
se asignan recursos adicionales. Por otro lado, si la aplicación interna o el cambio
se considera que tiene un impacto o mantenimiento menor, se asigna al Software
Programador, Analista Programador o Administrador SAP, y realizado directamente en el
entorno de producción. Por lo tanto, no hay evidencia como metodologías de prueba, planes de prueba.
y resultados, y cronogramas de implementación del proyecto, que se mantienen para este tipo de cambios.
Tampoco existe un entorno separado establecido para desarrollar o probar estos "menores
impacto ”aplicación interna o cambios.
Cuando se determina que son importantes, se trabajan las aplicaciones internas o sus cambios
en un entorno de desarrollo separado de la producción. Aplicación completa y respaldo de datos
Las actualizaciones no se realizan antes de desarrollar la aplicación interna o implementar la
cambios. No obstante, los procedimientos de prueba están documentados y los resultados satisfactorios respaldan la
implementación. Las pruebas las realizan usuarios seleccionados del área de TI y de negocios. Prueba
Los procedimientos realizados consisten en recrear transacciones de operación normal y verificar /
monitorear la precisión de los resultados. Los procedimientos de prueba también validan la integridad y la
integridad de la información. Después de realizar las pruebas y para garantizar una segregación adecuada
de tareas, los programadores no pueden migrar sus propios cambios a la producción
medio ambiente. En cambio, entregan su trabajo a personal independiente que no es programador.
(equipo de control de calidad, por ejemplo) para la migración al entorno en vivo.
Tanto el I&O Manager como el ASP&S Manager, indican que para gestionar y
mantener el control de versiones, un Administrador de configuración de control de versiones de software (SVCCM)
se utiliza la herramienta. Esta herramienta permite la identificación de cambios, etiquetándolos por “número de revisión
ber "," carta de revisión "," nivel de revisión "o simplemente" revisión ". Las revisiones de cambios están asociadas
con una marca de tiempo y el nombre del usuario que realiza el cambio. La herramienta SVCCM también
permite comparar y restaurar revisiones, así como combinarlas con otros tipos de archivos.
El proceso anterior no se ha documentado formalmente en forma de política o procedimiento,
ni establece cómo evita cambios no autorizados en las aplicaciones internas.
Además, actualmente no hay ningún proceso de sistema de gestión o control de versiones utilizado o en
lugar para las aplicaciones adquiridas por la entidad. La información anterior también fue corroborada
con el programador de software del cliente, el programador analista y el administrador de SAP.
Bases de datos
El proceso de la entidad para adquirir e implementar bases de datos es similar al que se
canalizados para aplicaciones compradas, según el Director de TI y el Gerente de I&O. los
El proceso de mantenimiento de bases de datos es diferente. Cambios en las bases de datos que respaldan todos los
Las aplicaciones, a excepción de Legacy System y Kronos, dependen principalmente de la aplicación.
cambios y, por lo tanto, están sujetos a los mismos procedimientos de mantenimiento de aplicaciones anteriormente
descrito. Ambas bases de datos patentadas que admiten el sistema heredado y las aplicaciones de Kronos
son administrados y mantenidos por programadores de aplicaciones (es decir, programador de software,
Analista Programador y Administrador de SAP). Por conversación con estos programas
usuarios, siempre que se necesite un informe o información particular de cualquiera de estas bases de datos,
Página 313
Los programadores acceden a las bases de datos en vivo para enviar un trabajo o generar consultas apropiadas para
producir el informe deseado.
La arquitectura de la base de datos para SAP, Bill-Inv System y APS2 es una base de datos separada,
accedido por la aplicación financiera correspondiente. Por otro lado, la arquitectura de la base de datos
para el sistema heredado y Kronos es una base de datos integrada o individual utilizada por el
aplicación relevante.
Como se discutió con el especialista en soporte de bases de datos, los diccionarios de datos contienen definiciones
y representaciones de los elementos de datos almacenados en las bases de datos de la entidad. Ejemplos de estos
serían definiciones precisas de elementos de datos, restricciones de integridad, procedimientos almacenados,
estructura de base de datos general y asignaciones de espacio, entre otros. Definición del formato de un
El campo de número de teléfono sería un ejemplo de uno de los usos de un diccionario de datos. Si tal
El formato está definido en el diccionario de datos, el campo será consistente en toda la base de datos.
incluso si varias mesas diferentes contienen números de teléfono. Diccionarios de datos para todos los comprados
Las aplicaciones solo se mantienen con el propósito de definir las relaciones de datos entre
entidades, estructuras de datos / campos y para representar elementos de datos. Estas tareas se utilizan de forma consisten
con atención a lo largo de los diccionarios de datos de la entidad. Diccionarios de datos para la aplicación interna
Las funciones se han definido en el propio código de la aplicación.
Redes
Excepto HR&P (subcontratado a la organización de servicios de ADP), todas las aplicaciones relevantes
son compatibles con la red local. Como se discutió con el administrador de red / LAN,
la red consta de un solo dominio en el que todos los usuarios están agrupados y divididos mediante un
estructura jerarquica. Los equipos cliente y los periféricos de la entidad están conectados a través de
cambia a los servidores ubicados en la sala de informática. Estos servidores están protegidos mediante dos
cortafuegos. Un diagrama de infraestructura de red, incluidas las ubicaciones que están en red.
en conjunto, el equipo utilizado, las actividades que son apoyadas por la red relevante
aplicaciones y las interrelaciones dentro de la red no está disponible.
Según el administrador de red / LAN, siempre que cambie la configuración, se actualice,
y / o se requieren nuevos cambios en el software de red (con frecuencia cambios relacionados con el firewall),
estos no los solicitan los usuarios habituales, sino el personal de TI. Los usuarios a menudo no tienen la
experiencia técnica o experiencia para definir los requisitos de la solución de red. Red-
las solicitudes de cambio relacionadas son revisadas y aprobadas por el Gerente de I&O. Una vez requerido
aprobados, los cambios necesarios son realizados por personal interno (normalmente
el administrador de red / LAN) con el apoyo de proveedores o redes externas
consultores, según corresponda. Luego, los cambios se prueban antes de la implementación en
producción. Las instalaciones de cambios se realizan fuera de las horas pico con el fin de minimizar
imitar la interrupción de los servicios. El proceso de solicitud, prueba e implementación de la red
los cambios se realizan verbalmente y no se mantiene documentación que respalde los procedimientos
realizado. Si se documenta, esta información se conservaría para proporcionar información para el
apoyo general de la red, particularmente durante las actividades de mantenimiento o si se
ocurren rupturas.
Sistemas operativos
Como se discutió con el especialista en soporte de sistemas operativos, el proceso para adquirir o / s
es similar al proceso seguido para las aplicaciones (consulte arriba). Procedimientos establecidos para
Página 314
implementar y mantener (probar) las operaciones de la entidad que respaldan las aplicaciones financieras relevantes
seguir:
◾ UNIX AIX VX (SAP): los cambios o actualizaciones a UNIX AIX VX los proporciona
el proveedor, IBM. Todas las actualizaciones se instalan directamente en el entorno de producción.
ment, porque no hay entornos separados disponibles para probar UNIX AIX VX
cambios. Como control de mitigación, antes de la implementación de UNIX AIX cambia
o actualizaciones a producción, copia de los o / s existentes, así como sus datos de aplicación
están respaldados, lo que permite al personal de TI local restaurar el sistema a su estado anterior,
en caso de que se produzcan interrupciones en el procesamiento como resultado del cambio del sistema operativo.
◾ OS 400 VX (sistema Bill-Inv y APS2): todas las pruebas relacionadas con los cambios en OS 400 VX
se realiza en un entorno de prueba separado para evaluar cualquier impacto que requiera
los cambios pueden tener lugar en el propio sistema operativo o en el entorno de producción. Las pruebas también
la integridad, precisión e integridad de la información alojada. Antes de implementar
de los cambios, se realiza una copia de seguridad del o / s, lo que permite la restauración del sistema a su
estado anterior, en caso de que surjan interrupciones en el procesamiento debido al cambio. Todos los cambios
se realizan fuera de las horas pico (normalmente durante los fines de semana), lo que permite a la entidad
para minimizar el tiempo de inactividad del sistema. Una vez probado, los cambios se implementan en producción
◾ Windows VX (sistema heredado): las actualizaciones de Windows se instalan directamente en
el entorno de producción porque no hay entornos separados disponibles.
Como control de mitigación, las actualizaciones que se consideran necesarias se implementan primero en
los servidores menos críticos deben someterse a pruebas de compatibilidad con aplicaciones existentes.
Documentación que respalde los planes y procedimientos de prueba realizados, así como los resultados de
las pruebas relacionadas con las actualizaciones de Windows no se guardan.
◾ Linux VX (Kronos): los cambios o actualizaciones a Linux no son frecuentes y
depende de la aplicación y la base de datos que aloja. Siempre que haya cambios / actualizaciones
son necesarios, estos los proporciona el proveedor del software. Según los sistemas operativos
Especialista en soporte, el proveedor de software realiza pruebas sobre esos cambios y
vides documentación de respaldo que acredite los resultados. Las pruebas realizadas aseguran
integridad, precisión e integridad de la información de la aplicación alojada. Sobre
La recepción, los cambios o las actualizaciones se instalan en el entorno de producción de Linux o / s.
Para todas las aplicaciones relevantes, los controles de aplicación predeterminados se validan para campos obligatorios, f
tipo y tamaño de entrada de datos. Estas aplicaciones también controlan los eventos numéricos y las transacciones.
(individual y secuencialmente) verificando así la responsabilidad entre los usuarios. Más lejos,
Los controles de aplicación predeterminados ejecutan mensajes de advertencia al personal de TI cuando se procesan los d
falla, o cuando los cálculos no se realizan de forma precisa ni completa. Los mensajes, con
descripción de las fallas, se almacenan en un archivo de registro para su posterior revisión. Consultas estándar generadas
comió informes diarios con totales de control y estadísticas para revisiones de salida, y con el fin de detectar
excepciones e inconsistencias. Estos informes se envían a las personas responsables o
departamentos para una revisión adicional y para corregir las excepciones señaladas.
Planes futuros
En términos de los planes de la entidad para actualizar o reemplazar las aplicaciones, bases de datos, redes,
y / o sistemas operativos en un futuro próximo, el Director de TI junto con el Gerente de I&O
Página 315
y ASP & S Manager, indican que evaluarán la posibilidad de actualizar el

versión actual de OS / 400 VX a una versión más reciente. La actualización a dicha versión actual es
se espera que tenga lugar durante el próximo año. No hay otros planes para actualizar o reemplazar los existentes
Los sistemas están configurados para el futuro inmediato.
TAREAS
1. Lea la descripción "Proceso de gestión del control de cambios y del entorno de TI" y
complete el Apéndice 2: Comprensión del entorno de TI.
2. A partir de la narrativa, identifique los hallazgos potenciales y enumerelos usando un formato de tabla.
Los nombres de las columnas son: “Descripción del hallazgo potencial”, “Área y / o aplicación
Afectados ”y“ Riesgo asociado con el hallazgo ”.
3. Respalde la justificación (el "por qué") de cada hallazgo potencial identificado y documente
en la tabla del # 2. Este también sería el riesgo o los riesgos asociados con cada hallazgo. ESO
plantea riesgos específicos para el control interno de una entidad, incluidos, por ejemplo, no autorizados
divulgación de datos confidenciales; procesamiento no autorizado de información; inapropiado
intervención manual; fallos del sistema; modificación no autorizada de información sensible
ción; robo o daño al hardware; y pérdida / robo de información, entre muchos otros.
4. Preparar una comunicación formal a la gerencia en forma de una Carta a la Gerencia.
Utilice el formato del Anexo 3.9 — Carta de gestión para preparar su comunicación.
Complete las secciones FINDING, IT RISK y RECOMENDATION del
Carta de administración, pero no incluya la sección RESPUESTA DE LA ADMINISTRACIÓN
ción. Nota: Para las recomendaciones, considere incluir posibles controles de TI que
creen que la gerencia debe implementar para abordar el riesgo y el hallazgo. Puedes utilizar
Apéndice 3 — Ejemplos de programas de auditoría de TI para áreas de TI de control general, como referencia,
para identificar los controles de TI. Suponga que la carta se enviará al Director de TI y al
el Director Financiero, y que una reunión preliminar con el Director de TI para
discutir estos hallazgos ocurridos un mes después de que finalizó el año fiscal de la Compañía. Por último,
no hay hallazgos repetidos de años anteriores que se incluyan en la carta.
Otras lecturas
1. Burgess, A. (2009). Fácil control de versiones con Git . Envato Pty Ltd. https://code.tutsplus.com/tutorials/
control-de-versión-fácil-con-git - net-7449
2. Common Weakness Enumeration (versión 2.10), http://cwe.mitre.org/ (consultado el 6 de abril de 2017).
3. Junta Ejecutiva Corporativa, Modelos de Gestión del Cambio , Consejo de Trabajo de Información del Jefe
Oficiales, enero de 2003.
5. Gallegos, F. y Yin, J. (2000). Auditing Oracle , EDP Auditing Series, # 74-15-37, Auerbach Publishers,
Boca Raton, FL, págs. 1-12.
6. Gallegos, F. y Carlin, A. (2000). Puntos clave de revisión para el desarrollo de sistemas de auditoría , auditoría de EDP
Serie, # 74-30-37, Auerbach Publishers, Boca Raton, FL, págs. 1–24.
7. Primeros pasos: acerca del control de versiones. https://git-scm.com/book/en/v2/Getting-Started-About-
Version-Control (consultado el 8 de junio de 2017).
8. Instituto de Auditores Internos. Guía de auditoría de tecnología global (GTAG) 8: Aplicación de auditoría
Control S. https://na.theiia.org/standards-guidance/recommended-guidance/practice-guides/Pages/
GTAG8.aspx (consultado en julio de 2017).
Página 316
9. Conceptos básicos de auditoría de SI. El proceso de auditoría de los sistemas de información. www.isaca.org/knowledge-center/
itaf-is-assurance-audit- / pages / is-audit-basics.aspx (consultado en julio de 2017).
10. Information Systems Audit and Control Foundation, declaración de prácticas de control de TI: AI6 Manage
cambios, Fundación de Auditoría y Control de Sistemas de Información, www.isaca.org/popup/Pages/AI6-
Manage-Changes.aspx
11. ISACA. (2017). Seguridad de las aplicaciones web: consideraciones comerciales y de riesgo. http://www.isaca.org/
Centro de conocimiento / Investigación / Entregables de investigación / Páginas / Seguridad-de-aplicaciones-web-Negocios-y-
Risk-Considerations.aspx
12. ISO / IEC 20000-1: 2011. Tecnología de la información. Gestión de servicios. Parte 1: Gestión de servicios.
Requisitos del sistema. www.iso.org/standard/51986.html (consultado el 8 de junio de 2017).
13. BMC Software, Inc. (2016). Gestión de cambios ITIL. www.bmc.com/guides/itil-change-management.
html
14. Kling, R. y Lamb, R. (2000). TI y cambio organizacional en las economías digitales: un enfoque sociotécnico
enfoque, En Understanding the Digital Economy: Data Tools and Research , Brynjolfrson, E. y Kahin,
B. Eds., MIT Press, Cambridge, MA, págs. 295–324.
15. Melançon, D. (2006). Más allá de las listas de verificación: un enfoque socrático para construir una auditoría de cambio sostenib
Prácticas, Asociación de Control y Auditoría de Sistemas de Información, Revista Online .
16. Morella, R. (agosto de 2015). Auditoría de aplicaciones web. Estrategias de auditoría de TI para aplicaciones web. ISACA
Semana Friki. www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2015/081115-
10:00 AM-WebAppSecurity.pdf
17. Instituto Nacional de Estándares y Tecnología. Publicación especial 800-53A, Revisión 4, Evaluación
controles de seguridad y privacidad en los sistemas y organizaciones de información federales, diciembre de 2014.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
18. Oseni, E. (2007). Gestión del cambio en el cambio de procesos, Auditoría y Control de Sistemas de Información
Asociación, JournalOnline .
6 (3), 841–849.
evaluación de control para organizaciones, IEEE Conference on Open Systems.
Nueva York.
Taylor y Francis, Boca Raton.
26. Asociación de la Industria de Software e Información (SIIA). Acerca de SIIA, http://www.siia.net/About/
Acerca de SIIA.
27. Oficina de contabilidad general de EE. UU. Manual de auditoría de controles del sistema de información federal: Vol. 1, financi
Auditorías de estados de cuenta, AIMD-12.19.6, junio de 2001.
28. Wallace, DR e Ippolito, LM Un marco para el desarrollo y la garantía de alta integridad
Software . Publicación especial NIST 500-223, diciembre de 1994, sección 3.4 “Configuración de software
Proceso de gestión". https://www.nist.gov/publications/framework-development-and-assurance-
software de alta integridad (consultado el 28 de marzo de 2017).
Página 317
Capítulo 11
Sistemas de información
Operaciones
1. Describir la importancia de las políticas y los procedimientos relacionados con la operación de los sistemas de inform
tanto para la organización como para los auditores.
2. Explique cómo el procesamiento de datos y los controles de salida juegan un papel importante en la integridad,
exactitud y validez de la información.
3. Analice las pautas y los controles para proteger los archivos y programas de datos.
4. Discutir los controles y procedimientos relacionados con el acceso de seguridad física.
5. Discutir los controles y procedimientos relacionados con los controles ambientales.
6. Discutir los controles y procedimientos relacionados con el almacenamiento y archivo de información.
7. Describa qué es un plan de continuidad empresarial y su importancia para la organización.
8. Explique qué es un plan de recuperación ante desastres y sus componentes. Discuta los objetivos y el procedimiento
duros al auditar dicho plan.
9. Describa la importancia de los grupos informáticos de usuarios finales y los pasos que se realizan cuando
auditar dichos grupos.
10. Describa la participación de la auditoría en un examen de operaciones de sistemas de información.
Dentro de un entorno de TI, los controles relacionados con las operaciones de los sistemas de información (SI) proporcionan
estructura para la gestión diaria de las operaciones y el mantenimiento de los sistemas existentes. ES
operaciones es también uno de los tres principales controles informáticos generales utilizados para evaluar las organizacione
políticas y procedimientos relacionados con los sistemas de aplicación para apoyar el funcionamiento eficaz
de controles de aplicación. Los ejemplos de controles generales dentro de las operaciones de SI abordan actividades tales
como supervisión de trabajos y seguimiento de excepciones hasta la finalización, acceso al programador de trabajos y datos
copias de seguridad y almacenamiento externo, entre otros.
Este capítulo presenta una descripción general de las operaciones de SI como un componente relevante de la infraestruct
estructura. Los objetivos y controles clave evaluados por las organizaciones y los auditores de TI (coherentes
con el Apéndice 3 del Capítulo 3), se refieren a:
291
Página 318
◾ Políticas y procedimientos operativos

◾ Procesamiento de datos
◾ Protección de archivos y programas de datos
◾ Seguridad física y controles de acceso
◾ Controles ambientales
◾ Copias de seguridad de programas y datos
◾ Plan de continuidad empresarial
◾ Plan de recuperación ante desastres
El capítulo analiza lo anterior y proporciona ejemplos de objetivos y actividades de control.

el auditor de TI debe enfocarse al examinar las operaciones de SI. El capítulo también describe al usuario final
grupos de computación (EUC) y proporciona pautas para auditar dichos grupos. Por último, auditoría de TI
La participación y los procedimientos se describen al examinar las operaciones de SI.
Política y procedimientos operativos

Cada entorno de TI debe tener políticas y procedimientos específicos que cubran las operaciones de SI
para garantizar que, como mínimo:
◾ Las operaciones de SI apoyan la programación, ejecución, monitoreo y continuidad de los programas de TI.
◾ Las operaciones de SI promueven el procesamiento y registro completos, precisos y válidos de
transacciones ness.
◾ Las instalaciones existentes protegen la integridad de la información comercial.
◾ Las operaciones de SI son adecuadas para salvaguardar el almacenamiento de archivos de datos y programas.
Los gerentes deben considerar la creación, revisión y actualización de políticas y procedimientos operativos como
un control muy importante. Se deben realizar actualizaciones y revisiones de estas políticas y procedimientos.
formado periódicamente. Esto se puede hacer observando la ejecución para determinar si tal
Las políticas y los procedimientos se siguen en realidad en las operaciones diarias de SI.
Los objetivos de auditoría al evaluar políticas y procedimientos requieren que las organizaciones proporcionen estándar
dards para preparar la documentación y asegurar el mantenimiento de dicha documentación. los
El gerente de operaciones de TI debe establecer estándares de documentación para que cuando los empleados cambien de tra
enfermarse o dejar la organización, el personal de reemplazo puede realizar adecuadamente la tarea de
ese empleado. El gerente de operaciones de TI también debe probar periódicamente la documentación para aclarar
integridad, integridad, idoneidad y precisión.
Los procesos y procedimientos relacionados con las operaciones de SI de una organización deben documentarse.
en forma de política organizativa. El Apéndice 7 ilustra un ejemplo de operaciones de SI
política.
Procesamiento de datos
Un ejemplo de procesamiento de datos, específicamente procesamiento de datos financieros, es la publicación diaria de
asientos del diario contable en el libro mayor de la organización. El procesamiento (o publicación) de estos
Las entradas de diario normalmente comienzan con un lote de entradas de diario no publicado y aprobado que está programa
uled para correr por la noche, o durante las horas de menor actividad. Si se procesa correctamente, el estado de la revista
Página 319
Operaciones de sistemas de información ◾ 293
el lote de entradas se cambia para indicar que las entradas de diario se han contabilizado. En otras palabras, el
Los asientos finales han actualizado el libro mayor. Si, por el contrario, se identificaran errores que prohíben
publicación exitosa de las entradas, se deben generar informes que detallen estos errores o excepciones.
Los controles de procesamiento de datos efectivos detectan estos a medida que ocurren y deben instar a los operadores de SI
corrección y resolución.
Como se vio, los controles de procesamiento de datos juegan roles interdependientes en la integridad, precisión y
validez de la información. Si uno de estos controles no funciona correctamente o no está autorizado
intervención anula los procesos de control complementarios, el sistema de procesamiento de datos se convierte en
vulnerable.
Estos controles pueden estar orientados a la prevención, detección o corrección de errores y abusos.
Los controles preventivos garantizan que los eventos se desarrollen según lo previsto. Los controles de detectives señalan un
finalizar una función y detener el procesamiento posterior cuando se infringe el sistema o se produce un error.
Los controles correctivos pueden realizar una alerta o terminar una función, pero también restauran o reparan
parte del sistema a su estado adecuado.
Los errores en el procesamiento de datos generalmente se relacionan con la programación del trabajo y el monitoreo r
Procesando. De hecho, un elemento importante de cualquier conjunto de políticas y procedimientos debería ser la
requisito de que los operadores de SI mantengan registros en los que se registren eventos inusuales o fallas
desde el procesamiento de los datos se registran, según el tiempo y en detalle. Estos registros se pueden utilizar para
identificar tendencias desfavorables, detectar accesos no autorizados y proporcionar una fuente de datos para determinar
la causa raíz de las fallas del sistema. Además, para abordar eventos inusuales, fallas o errores, los gerentes
debe hacer las siguientes preguntas clave:
1. ¿Hay controles adecuados configurados para reducir los errores de procesamiento de datos y mantener el
integridad de los datos procesados?
2. ¿Se utiliza una herramienta automatizada para ejecutar trabajos programados regularmente relacionados con aplicacion
bases de datos y sistemas operativos, como interfaces programadas de datos, purgas de datos, tablas
actualizaciones, etc.?
3. ¿Cuáles son los tipos de trabajos programados?
4. Cómo se realizan los cambios, como agregar, modificar y eliminar trabajos y programaciones, y
¿Quién puede hacer esos cambios?
5. ¿Utiliza el sistema verificaciones de procesamiento para detectar errores o datos erróneos durante la
cesando? Si es así, ¿qué controles?
6. ¿Cuál es el proceso utilizado para monitorear la finalización exitosa del procesamiento del trabajo?
7. Cómo el proceso de monitoreo y revisión asegura que las excepciones o fallas identificadas durante
el procesamiento del trabajo se resuelve a tiempo?
8. ¿Hay técnicas disponibles para detectar el reprocesamiento erróneo de datos?
9. ¿Quién es responsable de la revisión y el seguimiento de excepciones del reprocesamiento erróneo de datos?
10. Qué informes se revisan y qué sistemas y mecanismos de notificación se encuentran actualmente en
¿sitio?
Controles que siguen al procesamiento de datos y que también son fundamentales para garantizar la precisión,
ness y entrega de información se denominan controles de salida.
En el entorno automatizado actual, la mayoría de los resultados se publican en línea o se imprimen y procesan.
por máquinas. Es importante tener controles de integridad y precisión desde el momento en que
la salida se procesa hasta que se publica en línea o se entrega. Además, seguridad, confidencial-
La privacidad y la privacidad deben mantenerse desde el momento en que se crea la salida hasta que se entrega a
la fiesta apropiada. Si la salida del procesamiento de información se muestra en línea o en
Página 320
en papel, se necesitan controles de salida tradicionales para garantizar la precisión e integridad de

la información. Los controles de salida incluyen comprobaciones de equilibrio e integridad, por ejemplo, para
confirme que el número de páginas procesadas se crea para impresión en línea o en papel. Esto puede
lograrse creando un total de páginas antes y después de publicar o imprimir la salida para
comparación. La exactitud se puede confirmar seleccionando campos de datos clave para comparar antes y
después del procesamiento de salida. Los controles de salida también deben poder detectar dónde se encuentra la informació
desaparecido. Sería difícil determinar el problema a partir del recuento de páginas cuando miles
de páginas se imprimen y no hay forma de determinar dónde ocurrió el error. Adicionalmente,
Es necesario que exista un proceso para recrear todos o un subconjunto de documentos en los que se producen errores de sal
descubierto. Se necesitan controles adicionales para información sensible (por ejemplo, cheques, clientes
listas, secretos comerciales, datos de nómina, datos de propiedad, etc.) ya que los documentos originales pueden necesitar
ser destruido y esto debe controlarse cuidadosamente para verificar la destrucción de tales
información.
En una auditoría de TI, un objetivo común dentro de esta área sería determinar si SI opera-
apoyan la adecuada programación, ejecución, monitoreo y continuidad de los sistemas,
gramos, y procesos para asegurar el procesamiento y registro completos, precisos y válidos de
Transacciones financieras. Algunas de las actividades de control que el auditor de TI puede evaluar se relacionarían con
si (1) el procesamiento por lotes y / o en línea ha sido definido, ejecutado a tiempo y monitoreado para
finalización exitosa y si (2) excepciones identificadas en el procesamiento por lotes y / o en línea
se revisan y corrigen oportunamente para garantizar un procesamiento preciso, completo y autorizado de la
información financiera. Abordarlos garantizará que los datos se procesen de manera válida y que cualquier
las excepciones observadas durante el procesamiento se han detectado y corregido.
Protección de archivos y programas de datos

Cada entorno de TI debe tener una biblioteca de datos que controle el acceso a los archivos de datos, programas y
documentación. Un importante control de la biblioteca de datos se centra en garantizar que todos los medios de archivo
etiquetado de forma clara y precisa. Es decir, las etiquetas externas deben colocarse o marcarse sobre los datos
los propios medios. En los cartuchos de cinta y los paquetes de discos , generalmente se colocan etiquetas sensibles a la pr
para identificar tanto el volumen como el contenido del archivo. Deben existir procedimientos para asegurar que todos
las etiquetas estén actualizadas y que toda la información que contengan sea precisa.
La biblioteca de datos debe garantizar que solo las personas autorizadas reciban archivos, programas o documentos.
y que estas personas reconozcan su responsabilidad en el momento de cada emisión. Cada
Una vez que se elimina un archivo para su procesamiento, los controles sobre los archivos de datos deben garantizar que se
generado y devuelto a la biblioteca. Si es apropiado para el sistema de respaldo en el lugar, tanto emitido como
Los archivos nuevos deben devolverse junto con la versión anterior que sirve como respaldo.
El control se mejora al mantener un inventario de medios de archivo dentro de la biblioteca de datos. En otra
En palabras, debe existir un registro de inventario para cada cartucho de cinta o paquete de disco. El registro debe
anote cualquier utilización o actividad. Después de un número determinado de usuarios, se limpia el medio de archivo o el d
y recertificado. Además, si se encuentra algún problema al leer o escribir en el dispositivo,
Se toman y se anotan los pasos necesarios.
Idealmente, se asignará como bibliotecario de datos a una persona a tiempo completo independiente de las operaciones
Sin embargo, en entornos de TI más pequeños, tal asignación podría no ser económicamente viable. Cuando
un entorno no puede permitirse un bibliotecario de datos a tiempo completo, este deber de custodia debe estar segregado
de las operaciones. Es decir, para que el control sea adecuado, la función de bibliotecario debe asignarse como
una responsabilidad específica para alguien que no tiene acceso al sistema.
Página 321
Controles de acceso y seguridad física

El objetivo de la seguridad física y los controles de acceso es prevenir o disuadir el robo, daño y
acceso no autorizado a datos y software, y control de movimiento de servidores, relacionados con la red
equipos y dispositivos adjuntos.
Los controles de seguridad y acceso físicos protegen y restringen el acceso a los centros de datos (computadoras
salas) y áreas EUC donde los intrusos podrían acceder a los recursos de información (es decir, oficinas y redes
equipo). Los controles de acceso y seguridad física generalmente incluyen:
◾ Cerraduras tradicionales
◾ Sistemas de entrada de credenciales de personal
◾ Puertas magnéticas con código de seguridad para la sala de servidores
◾ Equipos de circuito cerrado de televisión y videovigilancia.
◾ Autenticación biométrica (por ejemplo, escaneos de retina, huellas dactilares, etc.)
◾ Alarmas de seguridad
◾ Registros de visitantes
◾ Guardias de seguridad y recepcionistas para examinar a los visitantes
La autoridad para cambiar los controles de acceso de seguridad física antes mencionados debe ser adecuadamente
controlados y limitados al personal apropiado (por ejemplo, gestión de recursos humanos, etc.)
Otros controles implican la colocación de equipos de oficina y de red para mayor seguridad.
Por ejemplo, el equipo de red debe colocarse en áreas donde el tráfico de la oficina sea ligero. Si pos-
sible, los servidores, impresoras y otros equipos deben colocarse detrás de puertas de oficina cerradas. Datos
los gerentes de operaciones del centro pueden querer usar cerraduras de combinación para evitar la duplicación de llaves;
Otra alternativa es utilizar un dispositivo de bloqueo que funcione con tiras magnéticas o tarjetas de plástico, una
dispositivo conveniente cuando los empleados llevan regularmente tarjetas de identificación con fotografía.
El equipo de red debe estar conectado a equipo de oficina pesado e inamovible, permanente
accesorios de oficina, recintos especiales o estaciones de trabajo especiales para microcomputadoras. El archivo adjunto pue
lograrse con dispositivos de bloqueo, que consisten en una base unida a accesorios permanentes y un
segunda base de enclavamiento adjunta al equipo de microcomputadora. Las bases se bloquean juntas y
Se requiere una llave, combinación o fuerza extrema para quitar el equipo. Todo el equipo de red
deben estar bloqueados para evitar movimientos, instalaciones o accesorios no autorizados.
Muchas microcomputadoras y otros equipos conectados a la red pueden contener costosos
hardware y dispositivos sensibles a la seguridad. La eliminación de estos dispositivos no solo implica el reemplazo
costos, pero también podría hacer que el software falle y permitir la divulgación no autorizada de
información sensible. El equipo interno puede protegerse mediante dispositivos de bloqueo, como anteriormente
discutido, y cerraduras especiales que reemplazan uno o más tornillos y aseguran la parte superior del equipo.
El cableado también es una fuente de exposición a daños o pérdidas accidentales o intencionales. El cableado habilita
usuarios y equipos periféricos para comunicarse. En muchas redes, si el cable está cortado o dañado
envejecido, todo el sistema se verá afectado. El cableado no debe ser accesible para el entorno
ment o individuos. El gerente de comunicaciones puede querer enrutar y encerrar el cableado en un
conducto eléctrico. Si es posible y si la exposición justifica el costo, el cableado también se puede encapsular en
tubería de hormigón. Cuando el cable está revestido, se reduce el acceso no autorizado a través de la conexión.
Además, el movimiento no autorizado del cableado no ocurrirá fácilmente, y esta situación
Permitir al administrador de la red monitorear y controlar de manera más eficiente la red y el acceso a
eso. Para aliviar el posible tiempo de inactividad, el cable se puede tender en pares. En este arreglo, si un juego es
dañado, el juego alternativo se puede colocar fácilmente. El segundo par suele estar protegido en el mismo
Página 322
manera que el original, pero no está encerrado en el mismo tubo, evitando así un tipo similar de
accidente por dañar ambos cables.
Computadoras portátiles y dispositivos móviles que se utilizan con fines laborales (por ejemplo, tabletas,
teléfonos, etc.) también deben recibir el mismo cuidado y atención que se mencionó anteriormente. Estos son aun mas
vulnerables en el sentido de que pueden ser llevados y utilizados fuera del sitio por los empleados y luego devueltos al
oficina y adjunto a la red. Vulnerabilidad externa al robo y sabotaje, como virus o
el robo de programas y datos se reduce cuando se protege en una ubicación de almacenamiento segura fuera del sitio.
Controles ambientales
Todos los equipos de red y de TI funcionan en las condiciones diarias de la oficina (p. Ej., Humedad, temperatura,
flujo eléctrico, etc.). Sin embargo, un entorno de oficina específico puede no ser adecuado para un microordenador
debido a la ubicación geográfica, las instalaciones industriales o los hábitos de los empleados. Un problema principal es el
Sensibilidad del equipo de microcomputadoras al polvo, agua, alimentos y otros contaminantes. Agua y
Otras sustancias no solo pueden dañar el equipo informático, sino que también pueden causar electrocución o un
fuego. Para prevenir tales incidentes, el gerente de operaciones de SI debe adherirse a una política de prohibición
alimentos, líquidos y similares en o cerca de los servidores y equipos de red.
Aunque la mayoría de las oficinas tienen aire acondicionado y la temperatura y la humedad
controladas, estas condiciones deben ser evaluadas por el gerente de operaciones de SI. Si por alguno
razón por la que el entorno no está controlado, el gerente de operaciones de SI debe tomar lecturas periódicas
de la temperatura y la humedad. Si la temperatura o la humedad es excesivamente alta o baja, el
El equipo del servidor y la red deben apagarse para evitar la pérdida de equipos, software,
y datos. Cuando se transporta un servidor o equipo de red, ya sea dentro del edificio o especialmente
cialmente al aire libre a una nueva ubicación, el equipo debe dejarse inactivo en su nueva ubicación durante un breve
tiempo para permitirle adaptarse a las nuevas condiciones ambientales.
Los contaminantes transportados por el aire pueden ingresar al equipo y dañar los circuitos. Los discos duros son
susceptible a daños por polvo, polen, aerosoles y humos de gas. Polvo excesivo entre la lectura /
El cabezal de escritura y el plato del disco pueden dañar el plato o el cabezal o causar daños a los datos o al pro-
gramos. Si hay mucho humo o polvo, los servidores deben trasladarse a otra ubicación. Estático
la electricidad es otro contaminante del aire. El uso de alfombras antiestáticas puede reducir la electricidad estática
así como almohadillas colocadas alrededor del área del servidor, almohadillas antiestáticas para sillas y teclados, y aerosoles
que se puede aplicar a la suela de los zapatos. Las máquinas también se pueden utilizar para controlar la electricidad estática
en toda una habitación o edificio.
Las principales causas de daño a los servidores o al equipo de red son las sobrecargas de energía, los apagones y
caídas de tensión. Las sobretensiones o picos de tensión son fluctuaciones repentinas de voltaje o frecuencia en la
suministro trical que se origina en la utilidad pública. Son más frecuentes cuando el centro de datos está
ubicado cerca de una planta de generación eléctrica o subestación de energía. El repentino aumento o caída de potencia
El suministro puede dañar las placas electrónicas y los chips, así como provocar la pérdida de datos o software. Si
Los problemas de suministro de energía ocurren con frecuencia, se pueden conectar cables y dispositivos eléctricos especiale
prevenir el daño. Estos dispositivos se conocen comúnmente como protectores de sobretensión.
Los apagones son causados por una pérdida total de energía eléctrica y pueden durar segundos, horas o días.
Los apagones ocurren cuando el suministro eléctrico disminuye a niveles por debajo de lo normal durante varias horas.
o días. Aunque los apagones y caídas de tensión ocurren con poca frecuencia, son disruptivos para
operaciones de ing. Si los servidores son esenciales y la energía de respaldo normal de la organización se limita a
funciones necesarias, se puede comprar equipo especial de suministro de energía ininterrumpida (UPS)
específicamente para el servidor o equipo de red. El equipo UPS puede ser paquetes de baterías o
Página 323
generadores de gas. Los paquetes de baterías se utilizan normalmente solo para tareas a corto plazo (es decir, completar
un trabajo en progreso u operaciones de apoyo durante una transición a la energía del generador). A gas
Los generadores proporcionan energía a largo plazo y, posiblemente, podrían usarse indefinidamente.
Para evitar la pérdida o daño de equipos, servicios o instalaciones informáticas, la organización debe
implementar salvaguardas o controles tales como:
◾ Evitar sobretensiones transitorias y cortes en las fuentes de alimentación

◾ Proporcionar fuentes alternativas de energía en caso de fallas prolongadas de energía
◾ Instalación de dispositivos que estabilizan las fuentes de alimentación
◾ Proporcionar generadores de respaldo
◾ Protección de cables de potencia
Otros controles ambientales comunes y necesarios para evitar daños a los equipos informáticos.
incluyen equipos de extinción de incendios y pisos elevados. Sistemas de extinción de incendios (p. Ej., Rociadores contra in
sistema, extinción de incendios gaseosos, extinción de incendios por aerosoles condensados, etc.) son automáticos y no
requieren la intervención humana para controlar y extinguir incendios. Los pisos elevados se construyen arriba
piso de losa de concreto original del edificio, dejando el espacio abierto creado entre los dos para cableado
infraestructura de refrigeración o refrigeración.
Se debe utilizar un área de espera aislada para las entregas y la carga desde la computadora
salas de apoyo a actividades comerciales críticas. Todos los equipos informáticos y de red deben
asegurado físicamente con dispositivos antirrobo si se encuentra en un entorno de oficina abierta. Servidores y red
el equipo de trabajo debe colocarse en gabinetes con llave, armarios con llave o salas de computadoras con llave.
Copias de seguridad de programas y datos

Las leyes y regulaciones pueden requerir que las organizaciones mantengan o archiven su información y
registros durante un período de tiempo específico. Dichos archivos, si contienen información financiera u operativa
mación, permiten a la gerencia ejecutar análisis y comparaciones útiles en los que basar las proyecciones
ciones de operaciones futuras. En un entorno de TI, estos archivos o copias de seguridad consisten en copias de
programas importantes (es decir, sistemas operativos, aplicaciones y bases de datos) y sus datos relacionados
que se conservan y almacenan en lugares de almacenamiento seguros. Si no se realiza una copia de seguridad de los program
regularmente ni almacenados en un lugar seguro, pueden no ser recuperables en caso de un grave
fallo de sistema.
Según el tipo de archivo de datos del que se haga una copia de seguridad, el período de retención puede variar. Para exa
Por ejemplo, las leyes y regulaciones pueden requerir que las organizaciones mantengan copias de seguridad de los datos de
número especificado de años, mientras que la política interna puede permitir que ciertos datos detallados de transacciones
eliminarse después de un período de tiempo más corto. Además, si se violan las leyes y regulaciones de retención de datos,
las organizaciones podrían estar sujetas a sanciones y / o multas reglamentarias.
El establecimiento de políticas, procedimientos, estándares y / u orientación de respaldo asegura la disponibilidad
de datos importantes para el funcionamiento de la organización. Las políticas, procedimientos, estándares y / o
la orientación debe cubrir áreas tales como:
◾ Almacenamiento y retención de programas y datos

◾ Programación y rotación de copias de seguridad
◾ Protección de los medios de respaldo
◾ Monitoreo de respaldo, revisión y resolución de excepciones
Página 324
Las organizaciones deben almacenar las copias de seguridad en el sitio (en una biblioteca de cintas, por ejemplo) y fuera de
Por lo general, las copias de seguridad de programas y archivos de datos se almacenan en el sitio y fuera del sitio. La organiz
Las políticas y los procedimientos deben exigir que las copias de seguridad de los programas y los datos reflejen los últimos
y versiones actualizadas. Las organizaciones deben utilizar sistemas de retención de ciclos para proporcionar respaldo de la
alquiler de datos. Archivos maestros y archivos de transacciones que sean suficientes para recrear el maestro del día actual
Los archivos deben almacenarse tanto dentro como fuera de las instalaciones. Los nuevos archivos de copia de seguridad de
ubicación de las instalaciones antes de que los archivos antiguos se devuelvan al centro de datos.
Las copias de seguridad deben programarse para que se ejecuten automáticamente durante los ciclos de copia de segurid
mensual, anual, trimestral y / o semestral) según el tipo de datos. Los datos pueden clasificarse
clasificados como datos sensibles, datos operativos y financieros, datos generales y públicos, etc. Por ejemplo,
una organización puede programar copias de seguridad incrementales o diferenciales parciales de todos los datos financiero
todos los días, y una copia de seguridad completa del sistema de todos los datos de la organización todos los viernes y el ú
el mes. La misma organización puede programar copias de seguridad adicionales parciales o completas de
datos confidenciales trimestrales y anuales. Las copias de seguridad también deben rotarse (idealmente a diario
base) y almacenados fuera del sitio. Normalmente, las cintas de respaldo que se han almacenado en el sitio en un lugar segur
bóveda durante algún tiempo se llevan a la instalación externa. La organización debe mantener la información
en qué cintas se encuentran en el sitio y fuera del sitio.
La protección de los medios de respaldo (por ejemplo, cartuchos de cinta, paquetes de discos que contienen datos y soft
Ware, etc.) deben ser parte de las políticas de respaldo de la organización. Las copias de seguridad in situ deben almacenarse
en la bóveda de un centro de cómputo, que debe estar restringido solo al personal autorizado (por ejemplo,
operadores de computadoras, bibliotecarios, supervisor del centro de computación, oficial de seguridad, etc.). No autorizado
El personal debe firmar un registro de visitantes y estar acompañado por personal autorizado antes de obtener
ing acceso. La bóveda del centro de cómputo debe estar protegida con elementos físicos y de acceso adecuados.
control S. De manera similar, las copias de seguridad fuera del sitio deben almacenarse en un área restringida a
personal solamente. La ubicación fuera del sitio también debe tener controles físicos y de acceso adecuados.
Las copias de seguridad almacenadas en el sitio y fuera del sitio deben revisarse con frecuencia para detectar pérdidas prema
deterioro de los medios de comunicación. Los medios de copia de seguridad son susceptibles a una degradación gradual a m
decae el rial. Se deben realizar procedimientos para identificar una posible degradación de los medios o una
creación de copias de seguridad para evitar la pérdida de datos. Escaneo periódico de los medios, verificación del
La creación de una copia de seguridad o la restauración de los datos normalmente indicará si los datos se pueden leer.
Cuando se descubre la degradación de los medios, los datos almacenados deben transferirse inmediatamente a
nuevos medios de comunicación. Cuando las copias de seguridad se escriben incorrectamente, debe existir un procedimiento
Repetir el proceso.
Las copias de seguridad deben monitorearse con frecuencia y los registros deben completarse que respalden tales
monitoreo y finalización exitosa de la copia de seguridad. La gerencia también debe revisar estos
registros por política de la empresa. Por ejemplo, cada mañana un operador de SI debe ser responsable
para verificar su computadora para confirmar la finalización de la copia de seguridad o identificar cualquier error
mensajes mostrados por el sistema que impidieron que se completara la copia de seguridad. Adicionalmente,
Los registros generados por el sistema deben ser examinados por el personal de operaciones de SI para identificar archivos.
que puede que no haya sido respaldado por el sistema. Cuando las excepciones al proceso de copia de seguridad
se identifican, el operador de SI debe intentar realizar procedimientos de reinicio para resolver
ellos. Si el operador no puede hacerlo, debe escalar el problema para su resolución.
Finalmente, si no puede corregir las excepciones, se debe contratar a un consultor o proveedor externo.
tacted para apoyo. El gerente de TI o SI debe revisar y mantener registros de control de todas las copias de seguridad,
así como proporcionar documentación, cuando sea necesario, sobre los procedimientos de recuperación realizados
y resultados de respaldo.
Página 325
Copias de seguridad en la nube

Las copias de seguridad en la nube pueden ofrecer el escenario perfecto e ideal para la organización del futuro. Con una nub
copia de seguridad, los archivos están disponibles en todas partes y ya no dependen de una sola computadora o
servidor, lo que permite una restauración rápida y sin problemas de los datos en caso de desastre. Adicional
Las ventajas de las copias de seguridad en la nube incluyen ahorrar dinero en costos de almacenamiento y la capacidad de re
con mayor frecuencia, así como disfrutar de un almacenamiento redundante y externo de datos críticos. Otra ventaja es
que las organizaciones pueden subcontratar servicios de copia de seguridad en la nube de entidades de terceros que se especi
copia de seguridad y protección de datos. Entonces, las organizaciones pueden eliminar muchos de los dolores de cabeza inv
respaldo de datos sin ceder el control de su activo más importante, la información. Estos espe-
Las entidades “subcontratadas” cializadas también ofrecen los últimos avances en seguridad, cifrado, recuperación de desast
y protección de datos continua en tiempo real, entre otros servicios.
Una investigación realizada por Forrester Consulting en 2014 concluyó que cada vez más organizaciones
Las empresas confían en las copias de seguridad en la nube para ayudar con sus tareas de continuidad y recuperación ante de
Según la investigación, aproximadamente el 44% de las organizaciones encuestadas ya han
transfirieron la mayoría de sus tareas de continuidad y recuperación ante desastres a la nube (incluyendo
copias de seguridad), o tiene planes de hacerlo en un futuro próximo. Otros encuestados expresaron preocupación porque
mover su información en la nube aún abriría oportunidades para la privacidad y la seguridad
problemas, y por lo tanto permanecerían con sus entornos de datos actuales. Todos los encuestados están de acuerdo
que el objetivo final, ya sea haciendo copias de seguridad en la nube o no, es tener la confianza de los conocimientos
que, en caso de catástrofe, la información estará protegida y disponible.
Plan de negocios continuo

El objetivo de un plan de continuidad del negocio (BCP) es describir procesos, pasos y / o procedimientos.
que se llevará a cabo en caso de una emergencia (es decir, un desastre natural o una interrupción no planificada
a las operaciones comerciales normales) para lograr una recuperación y disponibilidad oportuna de todos los negocios esenc
procesos, incluidos los sistemas de información. El BCP normalmente se dirige a:
◾ Ubicaciones clave de procesamiento informático

◾ Sistemas de aplicación y requisitos de usuario para procesos comerciales clave
◾ Actividades del usuario final para procesos comerciales clave
◾ Telecomunicaciones y redes
◾ Bases de datos clave, almacenes de información, etc.
◾ Recursos humanos
◾ Seguridad personal de empleados y otros
El plan ayuda a las organizaciones a responder a emergencias mientras continúa con las actividades y operaciones centrales.
Procesos de negocio críticos a un nivel aceptable para la dirección.
La falta de un BCP integral en caso de una emergencia puede traducirse en retrasos
restauración de procesos comerciales y sistemas de información. Esto puede resultar en la incapacidad del
organización para continuar las operaciones; pérdida de ingresos e incurrir en gastos innecesarios; pérdida
de ventaja competitiva; pérdida de confianza del cliente y participación de mercado; y multas y sanciones;
entre otros. En caso de emergencia, los servicios degradados pueden ser aceptables durante algún tiempo.
de tiempo. No obstante, el objetivo es restaurar los sistemas y servicios afectados a su nivel óptimo.
niveles lo más inmediato posible.
Página 326
Una actividad de control común probada por auditores de TI dentro de esta área implica si la organización
El BCP de la nación ha sido preparado y aprobado por la gerencia, basado en una evaluación de impacto comercial.
ment. Otros controles evalúan si el plan se prueba y actualiza regularmente para reflejar los resultados de
tales pruebas.
Plan de recuperación en un desastre

Desastres, ya sean naturales (por ejemplo, terremotos, tsunamis, huracanes, tornados, inundaciones, incendios, etc.) o
antinaturales (por ejemplo, ciberataques, interrupción del servicio, fraude, terrorismo, colapso del mercado, etc.) crean
caos económico y graves interrupciones comerciales. Es por eso que tener un plan de recuperación ante desastres
(DRP) en su lugar es una herramienta tan importante para las empresas.
Un DRP es una herramienta de supervivencia que ayuda a las empresas a responder a las amenazas y a recuperarse tras
evento que interrumpe las operaciones comerciales normales. Siempre que el plan sea respaldado por la gerencia,
actualizado con frecuencia y probado y mantenido en consecuencia, ofrece la oportunidad para que las empresas
sobrevivir. Si ocurre un desastre, la recompensa es recuperarse sin negocios u operaciones importantes.
tiempo de inactividad y pérdida. Los desastres pueden ocurrirles a las empresas en cualquier momento y pueden afectarlos s
con cautela. Por ejemplo:
◾ El 11 de septiembre de 2001, después del desastre de las Torres Gemelas de Nueva York, muchas empresas perdieron
conectividad a los bancos, agentes de bolsa y otras instituciones financieras, interrumpiendo su capacidad
para realizar negocios y determinar si las transacciones financieras como comprar y vender
acciones, etc., se habían ejecutado de forma completa y precisa.
◾ El 14 de agosto de 2003, un enorme corte de energía apagó los centros de población de Nueva
York a Cleveland, Detroit y Toronto, paralizando las redes de transporte y atrapando
decenas de miles de personas en metros, ascensores y trenes. Las computadoras se volvieron inútiles para
los que no tenían batería.
◾ Uno de los principales fabricantes de automóviles de Japón, Honda, sufrió una caída importante (casi el 90%) en su seg
ganancias trimestrales en 2011 después de que un tsunami masivo y un terremoto golpearon su producción y
ventas. Las pequeñas y medianas empresas no habrían podido soportar este tipo de pérdidas.
◾ En 2013, parte de la Internet china cayó en lo que el gobierno llamó el mayor
ataque de denegación de servicio (DoS) que ha enfrentado. El ataque hizo máquinas y redes
servicios de Internet no disponibles e interrumpidos. Según el Wall Street Journal, el
El ataque fue un indicador de cuán susceptible es la infraestructura global de Internet.
El impacto de estos y muchos otros desastres relacionados lo siente no solo la empresa, sino también
proveedores y clientes que confiaban en ese negocio para sus productos y ventas.
Uno de los primeros pasos críticos en DRP es identificar quién es responsable del desastre distribuido
recuperación. ¿La recuperación de toda la tecnología es responsabilidad exclusiva de TI o de las unidades de negocio? La re
depende de quién tiene control sobre el hardware, el software y los datos. En la mayoría de los casos, TI y usuarios
deben trabajar juntos para identificar la información crítica y los recursos que deberán recuperarse
en caso de desastre.
Un DRP debe abordar la destrucción total y parcial de los recursos informáticos. Repartido
Los sistemas y sistemas de microcomputadoras deben incluirse en el plan. Funciones críticas que
se realizan en estas plataformas deben identificarse y establecerse procedimientos para restaurar
operaciones. Las microcomputadoras son una herramienta importante para el procesamiento del trabajo diario y la recuperac
de estas herramientas no deben pasarse por alto. Información sobre la configuración básica del microordenador,
Página 327
incluyendo hardware y software, deben mantenerse para facilitar la recreación del entorno de procesamiento
ambiente. Además, una copia de seguridad de los archivos de datos críticos debe mantenerse fuera del sitio junto con
y procedimientos de recuperación.
Un DRP debe basarse en el supuesto de que cualquier sistema informático está sujeto a varias diferencias.
entres tipos de fallas. En particular, deben existir procedimientos y ser probados para la recuperación de fallas.
o pérdidas de equipos, programas o archivos de datos. En el caso de fallas en el equipo, cada instalación
podría tener un acuerdo contractual que cubra el uso de un sitio alternativo con una computadora comparable
configuración. Ejemplos de estos son los sitios fríos y los sitios calientes. Un sitio frío es un edificio vacío que
está precableado para el teléfono y el acceso a Internet necesarios, además de un contrato con uno o más proveedores
proporcionar todo el equipo necesario dentro de un período de tiempo específico. Un sitio caliente, por otro lado,
se refiere a una instalación que no solo está precableada para el teléfono y el acceso a Internet, sino que también contiene tod
equipos informáticos y de oficina que la organización necesita para realizar sus actividades comerciales esenciales.
Antes de montar un DRP, los activos de la organización (por ejemplo, hardware, software, instalaciones,
personal, administrativo, de datos, etc.) y sus valores de reemplazo deben identificarse. Riesgos específicos
que resultaría en la pérdida temporal o permanente de activos (por ejemplo, por incendio, inundación, sabotaje, virus,
etc.) también deben ser reconocidos. A continuación, el impacto de estas pérdidas (por ejemplo, modificación, destrucción, D
etc.) deben evaluarse. Finalmente, el valor del activo debe compararse con la frecuencia de pérdida.
para justificar la solución de recuperación ante desastres. Una vez completado lo anterior, se puede ensamblar un DRP.
Componentes DRP
El DRP debe identificar varios niveles de recuperación, desde un evento aislado hasta un desastre generalizado.
ter. La puntualidad de la recuperación dependerá de la pérdida de exposición para el programa en particular o
sistema. Cuando se completa el plan, debe probarse para identificar problemas potenciales. Pruebas
debe llevarse a cabo de forma periódica para validar los supuestos y actualizar el plan basado
en el entorno en constante cambio. Las pruebas también brindan la oportunidad de practicar
procedimientos de recuperación e identifique los elementos faltantes que puedan necesitar ser agregados. El DRP debería
componentes de dirección, como:
1. Declaración de objetivos y misión

2. Personal clave involucrado
3. Copias de seguridad completas e incrementales de programas y datos
4. Pruebas y simulacros
5. Copias de seguridad de programas y datos almacenadas fuera del sitio
6. Se designó al presidente y al comité de recuperación ante desastres
7. Números de teléfono de emergencia
8. Lista de todas las aplicaciones críticas de hardware y software
9. Cobertura de seguro
10. Planes de comunicación
11. Documentación actualizada del sistema y funcionamiento
12. Planes de reubicación de empleados a lugares de trabajo alternativos
Todos los miembros de la organización deben estar familiarizados con el DRP. Si ocurre una emergencia,
Sería fácil para los miembros del personal ejecutar sus roles en el plan. El ejercicio del plan confirma
que no se dupliquen los esfuerzos y se tomen todas las medidas necesarias. Es importante tener un escrito
diez DRP con pasos detallados ya que las personas que no están familiarizadas con el proceso pueden necesitar realizar el
proceso de recuperación ante desastres en una emergencia real.
Página 328
Auditoría de la informática del usuario final

Los grupos EUC han crecido rápidamente en omnipresencia e importancia. La aplicación del trabajador del conocimiento
La aplicación de tecnología para ayudar a las empresas a resolver problemas ha sido una de las principales fuerzas de cambi
en el negocio hoy. Prevalecerá el dominio del usuario. Los auditores, como trabajadores del conocimiento y usuarios, pueden
Ayudar a los departamentos a identificar aplicaciones de PC sensibles o críticas que requieren atención especial.
ción. En organizaciones donde los controles son inadecuados o inexistentes, los auditores pueden jugar un papel clave en
desarrollando estos controles para grupos EUC. Una vez establecidos los controles, los auditores pueden examinarlos
para su adecuación y eficacia. La auditoría de grupos de EUC puede abarcar todo el espectro de SI
revisiones desde el desarrollo de sistemas hasta la recuperación ante desastres. El Apéndice 8 cubre los pasos realizados cua
auditoría de grupos EUC.
Participación de la auditoría en las operaciones de los sistemas de información

Una auditoría de las operaciones de SI de una organización, por ejemplo, proporcionaría seguridad a los auditores de TI
que las operaciones, incluido el procesamiento de datos, estén adecuadamente diseñadas y garanticen la completa,
procesamiento y registro exactos y válidos de transacciones financieras, por ejemplo. Tal examen
ción también proporcionaría seguridad de que la información financiera y los componentes relevantes de la TI
la infraestructura se almacena y gestiona adecuadamente.
Sin embargo, operaciones y controles de SI insuficientes o inadecuados pueden resultar en lo siguiente:
riesgos:
◾ Procesamiento incompleto o inexacto de transacciones financieras, ya sea que se ejecuten en línea o

a través de un lote.
◾ Incapacidad para reconstruir (o restaurar) datos financieros a partir de la documentación de origen después de una
emergencia o un incidente o falla grave del sistema.
◾ El personal no autorizado puede acceder a las instalaciones, lo que puede resultar en pérdida o sustitución
tuación de datos, programas y salida o daño malintencionado a las instalaciones informáticas y
equipo.
Los objetivos comunes de una auditoría de operaciones de SI incluyen asegurar que:
◾ Las operaciones de TI apoyan la programación, ejecución, monitoreo y continuidad adecuados del sistema.
tems, programas y procesos para garantizar el procesamiento completo, preciso y válido y
registro de transacciones financieras.
◾ Las copias de seguridad de la información financiera se programan, administran y monitorean adecuadamente,
garantizar que la información sea precisa y completa. La información respaldada también es legible y
restaurado eficazmente sin mayores implicaciones.
◾ El acceso físico se gestiona adecuadamente para salvaguardar los componentes relevantes de la infraestructura de TI.
estructura e integridad de la información financiera.
Sin la implementación de controles apropiados, daños innecesarios o interrupciones en el

el procesamiento de datos de la organización podría ocurrir. Tal daño podría resultar en fallas de la organización
procesos críticos de la aplicación. Se deben implementar actividades de control para abordar riesgos tales como
encima. Por ejemplo, las actividades de control normalmente abordarían la integridad de las transacciones.
Entrada para procesamiento, incluyendo, entre otros, si las transacciones en línea se procesan de manera normal.
Página 329
finalización, todos los trabajos por lotes necesarios se procesan, el procesamiento se realiza a tiempo y en el
secuencia apropiada, y si el ingreso y procesamiento de transacciones es válido y efectivo.
Ejemplos de controles y procedimientos que normalmente emplean los auditores de TI al examinar datos.
el procesamiento incluye:
◾ El procesamiento por lotes y / o en línea se define, ejecuta oportunamente y se monitorea para

terminación.
◾ Las excepciones identificadas en el procesamiento por lotes y / o en línea se revisan y corrigen oportunamente
para garantizar un procesamiento preciso, completo y autorizado de la información financiera.
Para garantizar que las copias de seguridad sean efectivas y que la información sea precisa, completa y restaurada sin mayor
implicaciones, los auditores de TI pueden evaluar y probar actividades de control tales como si:
◾ Se han realizado procedimientos para la restauración y recuperación de información financiera a partir de

implementado en caso de interrupción del procesamiento, procedimientos de apagado y reinicio.
◾ Se han implementado herramientas de respaldo automatizadas para administrar planes de retención de datos y
horarios.
◾ Las copias de seguridad se controlan, se etiquetan adecuadamente y se almacenan en un lugar externo protegido ambie
y rotado a dicha instalación de forma periódica.
◾ Plan de gestión y programación (1) copia de seguridad y retención de datos y (2) borrado y liberación
de medios cuando la retención ya no es necesaria.
◾ La gerencia revisa periódicamente los registros de retención y liberación.
◾ Las copias de seguridad se archivan fuera del sitio para minimizar el riesgo de pérdida de datos.
◾ La administración revisa periódicamente la finalización de las copias de seguridad para garantizar la coherencia con la
y planes y cronogramas de retención.
◾ Las pruebas para la legibilidad de las copias de seguridad se realizan periódicamente. Soporte de resultados oportuno
y restauración exitosa de los datos respaldados.
◾ Los procedimientos para la restauración y recuperación de información financiera de copias de seguridad
Se ha implementado en caso de interrupción del procesamiento, procedimientos de apagado y reinicio.
coherente con las políticas y los procedimientos de TI.
Asegurar si el acceso físico se gestiona adecuadamente para salvaguardar los componentes relevantes de
la infraestructura de TI y la integridad de la información financiera, los auditores de TI pueden evaluar y probar
si:
◾ El acceso físico está autorizado, monitoreado y restringido a las personas que lo requieran.
acceso para realizar sus funciones laborales.
◾ Los usuarios tienen acceso al centro de datos o sala de computadoras. Si es así, qué usuarios.
◾ Un mecanismo de control de acceso físico (por ejemplo, tarjetas de acceso, datos biométricos, cerradura y llave tradici
guardias de seguridad, etc.) se utiliza para restringir y registrar el acceso al edificio y a la computadora
espacio, y la autoridad para cambiar dicho mecanismo se limita al personal apropiado.
◾ La autenticación biométrica se emplea a través de huellas dactilares, venas de la palma, reconocimiento facial, iris
reconocimiento, escaneos de retina, verificación de voz, etc.
◾ La entrada de personal no autorizado se supervisa y registra, y dicho registro se mantiene y
revisado periódicamente por la dirección de TI.
◾ Existen políticas y procedimientos para otorgar acceso al centro de datos.
◾ Las solicitudes y aprobaciones se requieren y se completan antes de que se otorgue el acceso físico.
Página 330
◾ Existe un proceso para cambiar el acceso de empleados transferidos y / o rescindidos

ees al centro de datos. Considere (1) nombrar al personal involucrado; (2) como estan siendo
notificado para eliminar dicho acceso al centro de datos; y (3) cómo se cambia el acceso oportuno a
reflejan su nuevo estado.
◾ Las revisiones de acceso de usuarios ocurren con frecuencia para respaldar el acceso físico actual otorgado a la TI.
entorno, y el centro de datos que aloja aplicaciones financieras, bases de datos, operaciones
ing sistemas y otros repositorios de información financiera.
Otros servicios típicos proporcionados por auditores de TI en el área de operaciones de SI y acceso físico
incluyen exámenes de centros de datos y DRP.
Auditoría de centros de datos

Las auditorías del centro de datos se realizan para evaluar los controles administrativos sobre los recursos del centro de dato
y personal de procesamiento de datos (operaciones de SI, análisis de sistemas y programación). El alcance de
la auditoría puede incluir una evaluación de la planificación, el personal, las políticas / procedimientos, la asignación
de responsabilidades, presupuestos, informes de gestión y medidas de desempeño en áreas, tales como:
gestión de hardware, gestión de software, protección y recuperación de recursos, controles de acceso,
gestión de operaciones y gestión de redes / comunicaciones. Una auditoría del centro de datos puede
centrarse en cualquiera de estas responsabilidades, o puede incluirlas todas dependiendo del tamaño de la
centro de datos, personal de operaciones y presupuesto de tiempo. Por ejemplo, para un gran centro de datos con múltiples
computadoras y una gran cantidad de usuarios, la auditoría puede centrarse solo en los controles de acceso y la seguridad
administración. Para un centro de datos pequeño, la auditoría puede incluir todas las responsabilidades.
Los objetivos comunes para las auditorías del centro de datos se relacionan con la identificación de los riesgos de audito
entorno ambiental y los controles establecidos para mitigar esos riesgos de auditoría de acuerdo con
intenciones del envejecimiento. El auditor de TI debe evaluar los mecanismos de control y determinar si
Se han alcanzado los objetivos. Se requiere preparación previa a la auditoría para que las auditorías del centro de datos sean
Estos incluyen reunirse con la gerencia de TI para determinar posibles áreas de preocupación. En este encuentro
ing, se debe obtener la siguiente información:
◾ Organigrama de TI actual
◾ Descripciones de trabajo actuales para empleados de centros de datos de TI
◾ Lista de software de aplicación compatible y el hardware que los aloja
◾ Políticas y procedimientos de TI
◾ Documentación de planificación de sistemas y presupuesto fiscal
◾ Planes de continuidad del negocio y recuperación ante desastres
El personal de auditoría de TI debe revisar la información anterior y familiarizarse con la forma

el centro de datos proporciona servicios de TI. Además, los auditores deben familiarizarse con los términos básicos
minología y metodología de definición de recursos utilizada en apoyo del entorno de operaciones.
El personal del trabajo de auditoría debe revisar el programa de auditoría y familiarizarse con las áreas
asignado para la realización de una tarea de auditoría.
Auditoría de un DRP
Como se indicó anteriormente, un DRP es un plan establecido para permitir que las organizaciones y sus entornos de TI
Restaure rápidamente las operaciones y reanude el negocio en caso de desastre. El plan debe actualizarse
Página 331
de forma regular para reducir la probabilidad de que se tomen decisiones incorrectas durante la recuperación
proceso y disminuir el nivel de estrés que se puede colocar en los miembros del equipo de recuperación de desastres
Durante este proceso.
Desde el punto de vista de la auditoría, el DRP que será evaluado y probado por el auditor de TI debe incluir
una declaración de misión y objetivos. Estos objetivos deben ser realistas, alcanzables y económicos.
cally factible. Los objetivos proporcionan una dirección en la preparación del plan y en la reevaluación continua.
su utilidad. La documentación que respalde los simulacros de simulación de desastres o las pruebas realizadas debe
estar disponible para evaluar aspectos de procedimiento técnicos y no técnicos del DRP de la organización.
Las pruebas reducen la posibilidad de errores de comunicación cuando el plan se implementa durante una
desastre. También ofrecen a la gerencia la oportunidad de detectar debilidades y mejorar los procedimientos.
Algunas de las actividades de control que el auditor de TI puede evaluar y probar se relacionarían con si:
◾ Todos los medios (cintas, manuales, guías, etc.) se almacenan en un lugar seguro con control ambiental.
ubicación.
◾ Se ha adquirido y mantenido una cobertura de seguro adecuada.
◾ La legibilidad continua de la copia de seguridad y los datos retenidos se prueba periódicamente mediante la restauració
u otros métodos.
◾ Los medios extraíbles están etiquetados para permitir una identificación adecuada.
Desafortunadamente, las organizaciones a menudo no están dispuestas a realizar una prueba debido a la interrupción que
ocurre con las operaciones diarias y el temor de que pueda surgir un desastre real como resultado del procedimiento de prueb
duras. Por lo tanto, un enfoque gradual de las pruebas sería útil para llegar a una prueba completa. UN
El enfoque de prueba por fases consideraría, por ejemplo, dar al personal un aviso previo de la prueba para que
están preparados. El enfoque también simularía el desastre con advertencia (es decir, en una conven-
tiempo oportuno y durante un período lento) y sin previo aviso.
A menos que se pruebe un DRP, rara vez permanece utilizable. Una prueba de práctica del plan podría muy bien ser
la diferencia entre su éxito o su fracaso. El proceso es paralelo al viejo adagio sobre los tres
cosas que se necesitan para que un negocio minorista tenga éxito: ubicación, ubicación, ubicación. Lo que se necesita para
El DRP de una organización para permitirle continuar en el negocio es realizar pruebas, pruebas y más pruebas.
La auditoría de un DRP es una verificación importante tanto para el auditor como para la administración de TI. El mayo
Los elementos y áreas del plan deben validarse y evaluarse para garantizar que, en caso de
desastre, los procesos comerciales esenciales y los sistemas de información se pueden recuperar a tiempo.
Herramientas de auditoria
La figura 11.1 ilustra una plantilla de una lista de verificación de auditoría estándar que se puede utilizar como punto de part
al evaluar las operaciones de SI relacionadas con los sistemas de aplicaciones financieras. Apéndice 3 (discutido en
El Capítulo 3) también proporciona un programa de auditoría de TI de muestra para el control general de TI de operaciones
área, que incluye una lista completa de los objetivos y actividades de control de auditoría a seguir y
realizado al realizar dicho examen. Dependiendo del tamaño y complejidad del
organización, estos objetivos y actividades de control pueden necesitar ser revisados o expandidos para obtener
cobertura de auditoría adecuada de la función de gestión del control de cambios.
Conclusión
El capítulo ha proporcionado una descripción general de las operaciones de SI como un componente relevante de la TI.
infraestructura. Esta descripción general incluye objetivos y controles clave que se relacionan con la importancia
Página 332
Figura 11.1 Muestra de lista de verificación de auditoría ISO

Operaciones de sistemas de información: lista de verificación de auditoría
[Nombre de] Sistema de solicitud financiera
Sí No,
OBJETIVO 1: Las operaciones de TI apoyan la programación, ejecución y

monitoreo y continuidad de sistemas, programas y procesos para
Asegurar el procesamiento y registro completos, precisos y válidos de
transacciones financieras.
1. Entreviste a los usuarios que estén familiarizados con el objetivo de control y

controlar las actividades enumeradas a continuación y pedirles que describan los pasos
involucrados en lograr y realizar dicho objetivo de control y
actividades, que incluyen pero no se limitan a:
• informes utilizados y cómo se utilizan
• procedimientos realizados cuando hay excepciones o elementos inusuales (por ejemplo,
cambios inesperados en el personal, etc.) impiden el control
objetivo y actividad de ser abordado
• cómo se logran el objetivo y la actividad de control en su
ausencia
2. Verifique que las herramientas de programación de trabajos automatizadas estén implementadas para
garantizar la integridad del procesamiento del flujo de datos.
3. Examinar la documentación que respalda los cambios en el horario de trabajo.

Obtenga la autorización de la gerencia para esos cambios.
4. Observe si el registro de cambios en la programación del trabajo

ha sido habilitado para confirmar que tales cambios son adecuadamente
supervisado.
5. Revisar el acceso de los usuarios que pueden definir o modificar la producción.

horarios. Reevaluar la razonabilidad de dicho acceso
privilegios.
6. Asegúrese de que la documentación existente defina por lotes y en línea

procedimientos de procesamiento.
7. Asegúrese de que haya documentación disponible que respalde la programación.

y ejecución oportuna del procesamiento por lotes y / o en línea
procedimientos.
8. Asegúrese de que el procesamiento por lotes y en línea se administre en

de acuerdo con las políticas y procedimientos establecidos.
9. Asegurar que los procedimientos de procesamiento por lotes y / o en línea sean monitoreados
para completar con éxito.
10. Examinar la documentación de la entidad, como el procesamiento completo.

registros y listados de control de acceso, indicando que el procesamiento es
monitoreado de acuerdo con las políticas establecidas y
procedimientos.
( Continuacion )
Página 333
Figura 11.1 ( continuación ) Muestra de lista de verificación de auditoría ISO

Sí No,
11. Observe la ejecución del procesamiento programado para confirmar que

las excepciones, si las hay, se registran correctamente en los registros.
12. Observe los procedimientos realizados para confirmar que las excepciones
identificadas en el procesamiento por lotes y / o en línea se revisan oportunamente
y corregido para asegurar que sea preciso, completo y autorizado
procesamiento de información financiera.
13. Garantizar el acceso a herramientas de programación automatizadas y ejecutables

programas (es decir, ejecutar, modificar, eliminar o crear) se otorga a
usuarios coherentes con sus tareas y responsabilidades laborales.
14. Documentación de muestra que se obtendrá para respaldar la auditoría

Los procedimientos anteriores pueden incluir:
• Programas de operaciones o listas de tareas
• Muestra de registro de procesamiento completo
• Políticas y procedimientos relacionados con las herramientas de programación de trabajos, así
como detección y corrección de excepciones de procesamiento
• Registros e informes de excepciones, errores o problemas
• Procedimientos de reinicio / recuperación
• Organigrama y listados de acceso (p. Ej., Programador de trabajos
función, archivo del planificador maestro, etc.)
OBJETIVO 2: El almacenamiento de información financiera es adecuado

administrado, preciso y completo.

ausencia
2. Procedimientos para la restauración y recuperación de fondos

la información de las copias de seguridad se ha implementado en el evento
de los procedimientos de interrupción, apagado y reinicio del procesamiento
3. Se han implementado herramientas de retención de datos automatizadas (copias de seguridad).

implementado para administrar planes y horarios de retención de datos.
( Continuacion )
Página 334

Sí No,
4. Se han revisado las herramientas de respaldo y los programas en línea

aprobado por la gerencia.
5. Observe la implementación y ejecución de las herramientas de respaldo.
6. Para errores resultantes de copias de seguridad, examine la evidencia

apoyando que tales errores han sido identificados y oportunos
resuelto.
7. Observe cualquier lugar de almacenamiento en el lugar y asegúrese de que esté protegido

y adecuadamente controlado.
8. Para las copias de seguridad externas, asegúrese de que estén almacenadas en un lugar seguro.
Ubicación ambiental.
9. Verificar la idoneidad de la ubicación de la instalación fuera del sitio, incluyendo

sistemas de seguridad física y controles ambientales.
10. Asegúrese de que las copias de seguridad estén debidamente etiquetadas y giradas a la
instalación fuera del sitio de forma periódica.
11.Asegúrese de que las pruebas de legibilidad de las copias de seguridad sean

realizado de forma periódica. Los resultados deben respaldar
restauración exitosa de los datos respaldados.
12. Examinar los datos almacenados y programar la eliminación o eliminación de

datos cuando ya no sean necesarios.
13. Documentación de muestra que se obtendrá para respaldar la auditoría

• Documentación de la herramienta de retención de datos automatizada, que incluye
informes de configuración y parámetros
• Ejemplos de informes de gestión generados a partir de
herramientas automatizadas de retención de datos
• Políticas y procedimientos sobre copias de seguridad automatizadas, etiquetado,
borrado, retención y eliminación
• Descripciones de trabajo y responsabilidades del custodio de registros
• Análisis de impacto empresarial sobre la disponibilidad de datos
• Muestras de registros de respaldo y programas de rotación
• Inventario de copias de seguridad en el sitio y fuera del sitio
OBJETIVO 3: El acceso físico se gestiona adecuadamente para salvaguardar

componentes relevantes de la infraestructura de TI y la integridad de
información nanciera.
( Continuacion )
Página 335

Sí No,

ausencia
2. Se utilizan mecanismos de control de acceso físico para restringir y registrar

acceso al edificio y a la sala de computadoras (es decir, centro de datos).
3. La autoridad para cambiar los mecanismos de control de acceso físico es

limitado al personal apropiado.
4. El acceso físico está autorizado y otorgado de manera apropiada y consistente

con responsabilidades laborales.
5. El acceso físico está supervisado y restringido a los usuarios que requieran

dicho acceso para realizar sus funciones laborales.
6. Se supervisa y registra la entrada de personal no autorizado. los

El registro es mantenido y revisado regularmente por la gerencia de TI.
7. Observar (sin previo aviso siempre que sea posible) al personal

acceder a las instalaciones mediante mecanismos de control de acceso.
8. Asegúrese de que la administración revise periódicamente las listas de acceso.

de personal con autoridad para acceder a recursos / instalaciones de TI y
cambiar los mecanismos de acceso físico. Corroborar que dicho acceso es
autorizado y otorgado de acuerdo con las responsabilidades del trabajo, y que
El personal no autorizado se retira inmediatamente.
9. Documentación de muestra que se obtendrá para respaldar la auditoría.

• Políticas y procedimientos de acceso a áreas restringidas
• Registros de seguimiento del mecanismo de control de acceso
• Políticas y procedimientos relacionados con la concesión / eliminación de acceso a
Recursos de TI y áreas restringidas, así como acceso al cambio
mecanismos de acceso físico
• Listado de usuarios que tienen acceso a recursos de TI y restringidos
áreas, y puede cambiar los mecanismos de acceso físico
• Evidencia de que las violaciones en el acceso se han corregido oportunamente.
Página 336
de implementar políticas y procedimientos efectivos; procesamiento de datos; seguridad física; envi-

controles ambientales; almacenamiento de información; y continuidad y recuperación de operaciones. Estas
Los controles operativos forman una base subyacente para la disponibilidad y seguridad del
todo el sistema, y son extremadamente importantes para proteger las aplicaciones y los sistemas de soporte.
Cualquier falla en su efectividad puede tener un impacto catastrófico en los programas y
aplicaciones.
1. Las políticas y procedimientos relacionados con las operaciones de SI se consideran esenciales para todos los entorno
ment, por qué?
2. Los controles de procesamiento de datos ayudan a garantizar que los datos se procesen de manera válida y que cualqui
anotado durante el procesamiento será detectado y corregido. ¿Cuáles son algunas de las preguntas clave
los gerentes preguntan para abordar eventos inusuales, fallas o errores resultantes de la
¿procesada?
3. ¿Por qué son importantes para las organizaciones la seguridad física y los controles de acceso? Enumere al menos seis
ejemplos de seguridad física y controles de acceso.
4. Explique el propósito de las auditorías del centro de datos.
5. Diferenciar entre apagones y caídas de tensión. Investigue en Internet y proporcione
un ejemplo de un apagón durante los últimos cinco años. Haz lo mismo con un
apagón.
6. Enumere las áreas potenciales que las políticas, procedimientos, estándares y / u orientación de respaldo deben
cubrir para asegurar la disponibilidad de datos importantes para el funcionamiento de la organización.
7. ¿Cuál es el riesgo para las organizaciones de no tener un plan integral de continuidad del negocio en
lugar en caso de emergencia?
8. Como auditor senior de TI, tiene una reunión de planificación con la gerencia de TI del cliente.
ment. El gerente de TI está en el proceso de crear un plan de recuperación de desastres (DRP) para poner el
organización en una mejor posición para responder (y recuperarse de) amenazas que pueden
interrumpir las operaciones comerciales normales. El gerente de TI le pregunta sobre los componentes que
debe incluirse en un DRP. Proporcione su respuesta.
9. Enumere las actividades de control que el auditor de TI puede realizar para evaluar y probar el DRP de una organizaci
10. Mencione las áreas potenciales que una política de la empresa relacionada con los grupos de informática del usuario fi
cubrir.
Ejercicios
1. Enumere la información que el auditor de TI debe solicitar u obtener en la reunión previa a la auditoría en
para realizar una auditoría del centro de datos. ¿Por qué esta información es importante para el auditor de TI?
2. Documentar los objetivos de auditoría comunes en los que el auditor de TI debe centrarse al auditar el almacenamiento
o archivo de información. Además, enumere las actividades de control que el auditor de TI necesitaría probar.
para cumplir con los objetivos de auditoría que se acaban de enumerar.
3. Una de las recomendaciones que hizo durante la auditoría de TI del año pasado fue la implementación
de un plan de recuperación ante desastres. Al realizar la auditoría de TI de este año, encontrará que aunque
había un plan en marcha, no ha sido probado. Documente sus razones por las que la recuperación ante desastres
el plan debe ser probado.
Página 337
4. Usted es el auditor senior de TI que lleva a cabo una reunión de auditoría de planificación con sus dos miembros del p
auditores. El tema principal discutido en esta reunión de planificación es la próxima auditoría de un
grupos de informática de usuario final (EUC) de la empresa. Uno de los auditores de TI del personal, contratado recie
de la universidad, no está seguro de los objetivos específicos a incluir al auditar grupos EUC.
Resuma y documente estos objetivos para el auditor de TI de su personal.
CASO: CONTINUIDAD DEL NEGOCIO Y RECUPERACIÓN DE DESASTRES
ESCENARIO: Se requieren planes de recuperación de desastres y continuidad del negocio para contrarrestar
interrupciones en las actividades comerciales y para proteger los procesos comerciales críticos de los efectos
de grandes fallas o desastres. El Departamento de Nómina ("Departamento") de la empresa ISO,
Inc. está clasificado como un proceso comercial crítico debido a la confidencialidad, privacidad y
información inicial que aloja. Sería desastroso para el Departamento si se pierde información
o si sus sistemas comerciales se desconectan, incluso por un día. Durante las reuniones de planificación, los auditores de
tuvo en cuenta los siguientes objetivos:
◾ ¿Se respaldan adecuadamente los sistemas comerciales del Departamento?

◾ ¿Se guardan las copias de seguridad de los datos del Departamento en un almacén de medios seguro y remoto?
◾ ¿Existe evidencia de que la estrategia de respaldo actual funciona en la práctica?
◾ ¿Existe un plan de recuperación de desastres adecuado establecido como parte del negocio de la empresa?
plan de continuidad de ness?
◾ ¿El plan de recuperación ante desastres se basa en una evaluación de riesgos exhaustiva?
OBSERVACIONES: Como parte de la auditoría de TI del Departamento de Nómina de TI de ISO Company, Inc.
Los auditores descubrieron una serie de problemas con la continuidad del negocio de la empresa y
ter planes y prácticas de recuperación. Al realizar la auditoría, los auditores de TI observaron que el
los planes de recuperación ante desastres y continuidad del negocio de la organización, ambos establecidos hace 10 años
no se han actualizado para reflejar las prácticas de continuidad y recuperación de desastres para el
medio ambiente. Por ejemplo, aunque se hicieron copias de seguridad de la información del Departamento
tras la inspección, los auditores de TI descubrieron que esas copias de seguridad no se mantenían
en la ubicación fuera del sitio donde se suponía que debían almacenarse. Además, cuando los auditores de TI
solicitó documentación que respalde las pruebas realizadas de los negocios del Departamento.
planes de recuperación ante desastres, descubrieron que el Departamento nunca había probado los
planes. El Departamento tampoco había realizado ninguna evaluación de riesgos en apoyo de los planes.
Los sistemas de información del Departamento, la Aplicación del Sistema de Nómina (PSA), están abiertos a
ataques externos ya que está interconectado a través de la red. Un colapso del PSA
traerá consecuencias nefastas para el Departamento. De hecho, en caso de accidente, cambiar
a un sistema manual no sería una opción. Manejo manual de la nómina de la empresa
información sensible, privada y confidencial del personal del personal ha dado lugar a
pérdida de dicha información. Por lo tanto, el PSA debe operar en línea en todo momento. Los auditores están de acuerdo
que, con base en las observaciones anteriores, en caso de interrupciones por desastres naturales,
accidentes, fallas del equipo y acciones deliberadas, es posible que el Departamento no pueda
hacer frente a la presión.
TAREA: Enumere los riesgos a los que está expuesto el Departamento de Nómina de ISO Company, Inc. como resultado
las observaciones. Además, documente las recomendaciones de auditoría que comunicaría a ISO
Página 338
La administración de Company, Inc. relacionada con la falta de continuidad y el procedimiento de recuperación de desas
duros observados. Respalde sus razones y justificaciones con literatura de auditoría de TI y / o cualquier
otra fuente externa válida. Incluya ejemplos, si corresponde, para evidenciar su caso.
Envíe un archivo de Word con una portada, respuestas a las tareas anteriores y una sección de referencia en
el fin. El archivo enviado debe tener al menos cinco páginas (interlineado doble), incluyendo
la portada y la página de referencias. Esté preparado para presentar su trabajo a la clase.
Otras lecturas
1. Barron, J. (15 de agosto de 2003). El apagón de 2003: el panorama general; la subida de tensión apaga el noreste,
golpeando ciudades en 8 estados y Canadá; los cierres del mediodía perturban a millones. The New York Times .
Fuente: http://www.nytimes.com/2003/08/15/nyregion/blackout-2003-overview-power-surge-blacks-
noreste-ciudades-que-golpean-8-estados.html
2. Bartolomé, D. (2014). Terremoto de Northridge: el terremoto de 1994 aún fresco en Los Ángeles
mentes después de 20 años. Noticias diarias de Los Ángeles . http://www.dailynews.com/general-news/20140111/
terremoto-de-northridge-1994-desastre-aún-fresco-en-los-ángeles-mentes-después-de-20-años
3. Forrester Research, Inc. (marzo de 2014). El respaldo en la nube y la recuperación ante desastres se encuentran con la próxima g
La base de datos exige que la nube pública pueda reducir los costos, mejorar los SLA y ofrecer una escala bajo demanda. http: /
scribd-download.com/cloud-backup-and-disaster-recovery-meets-next-generation- database-
demand_58c8d228ee34353a2ee07a3e_txt.html
4. Collins, T. (octubre de 2015). Seis razones por las que las empresas deberían elegir la copia de seguridad en la nube. Atlantech e
Inc. Fuente: https://www.atlantech.net/blog/6-reasons-businesses-should-choose-cloud-backup
5. Cox, R. (2013). 5 ataques DDoS notorios en 2013: gran problema para el Internet de las cosas.
SiliconANGLE Media, Inc. http://siliconangle.com/blog/2013/08/26/5-notorious-ddos-attacks-in-
2013-gran-problema-para-internet-de-las-cosas /
6. Deloitte LLP. (2014). Documentos de trabajo de auditoría de TI. Documento interno inédito.
7. Dobson Technologies . (2013). Informe técnico: 7 razones por las que las empresas están cambiando a la copia de seguridad en l
Fuente: http://www.dobson.net/wp-content/uploads/2013/04/7-Reasons-Businesses-are-Shifting-to-
Cloud-Backup-Dobson.pdf
8. Completa, incremental o diferencial: cómo elegir el tipo de copia de seguridad correcto. (Agosto de 2008).
TechTarget. Fuente: http://searchdatabackup.techtarget.com/feature/Full-incremental-or-differential-
Cómo elegir el tipo de copia de seguridad correcto
9. Govekar, M., Scott, D., Colville, RJ, Curtis, D., Cappelli, W., Adams, P., Brittain, K. et al. (Julio
7, 2006). Ciclo de bombo para la gestión de operaciones de TI, 2006 , Gartner Research G00141081, Stamford,
CONNECTICUT.
10. ¿Cuánto tiempo debe conservar sus datos? Revista Strategic Finance . Edición de enero de 2017.
11. Kageyama, Y. (1 de agosto de 2011). Las ganancias trimestrales de Honda se desploman ante el desastre. La Unión de San Diego
Tribuna. Fuente: http://www.sandiegouniontribune.com/sdut-hondas-quarterly-profit-plunges-on-
desastre-2011aug01-historia, amp.html
12. Plataforma de información de Microsoft. (Mayo de 2014). El estudio de Forrester Consulting encuentra costos, con-
tinuity se beneficia del respaldo en la nube y la recuperación ante desastres. Fuente: https://blogs.technet.microsoft.
com / dataplatforminsider / 2014/05/02 / forrester-consulting-study-find-cost-business-continuity-
beneficios de la copia de seguridad en la nube y la recuperación ante desastres /
13. Otero, AR, (2015). Una metodología de evaluación de control de seguridad de la información para organizaciones '
información financiera. Revista Internacional de Sistemas de Información Contable , 18 (1), 26–45.
14. Otero, AR (2015). Impacto de la participación de los auditores de TI en las auditorías financieras. Revista Internacional de
Investigación en negocios y tecnología , 6 (3), 841–849.
Página 339
controles que utilizan funciones booleanas. Revista internacional de aplicaciones y seguridad de redes , 2 (4), 1–11.
17. Paquet, R. (5 de septiembre de 2002). El mejor enfoque para mejorar los procesos de gestión de TI , Gartner
Investigue TU-17–3745, Stamford, CT.
19. Resumen de las “lecciones aprendidas” de los eventos del 11 de septiembre e implicaciones para la continuidad del negocio.
13 de febrero de 2002. Comisión de Bolsa y Valores. Fuente: https://www.sec.gov/divisions/
marketreg / Lessonlearned.htm
Página 341
340
Capítulo 12
Seguridad de información
1. Describa la importancia de la seguridad de la información para las organizaciones y cómo la información
representa un activo fundamental en las organizaciones empresariales actuales.
2. Analice las tecnologías recientes que están revolucionando los entornos de TI de las organizaciones y la
importancia de implementar una seguridad adecuada para proteger la información.
3. Discutir las amenazas y los riesgos para la seguridad de la información y cómo representan un desafío constante.
a los sistemas de información.
4. Describir los estándares y directrices de seguridad de la información relevantes disponibles para las organizaciones
y auditores.
5. Explique qué es una política de seguridad de la información e ilustre ejemplos de su contenido.
6. Discutir las funciones y responsabilidades de varios grupos de sistemas de información dentro de la información.
seguridad.
7. Explique qué son los controles de seguridad de la información y su importancia para salvaguardar la
información.
8. Describir la importancia de seleccionar, implementar y probar la seguridad de la información.
control S.
9. Describa la participación de la auditoría en un examen de control de seguridad de la información y proporcione
información de referencia sobre herramientas y mejores prácticas para ayudar en tales auditorías.
A lo largo de los años, las organizaciones han experimentado numerosas pérdidas, que han tenido un impacto directo
impacto en su activo más valioso, la información. Uno de los principales ataques recientes contra
información ocurrió en septiembre de 2017, donde los piratas informáticos obtuvieron acceso a los datos de Equifax * en un
hasta 145 millones de estadounidenses (casi la mitad de la población de los Estados Unidos (EE. UU.)
el último censo). Los piratas informáticos obtuvieron acceso y explotaron una vulnerabilidad en uno de los
Servidores web con sede en EE. UU. Los archivos pirateados incluían información personal, como nombres, fechas de nacim
números de seguro social y direcciones. Definitivamente fue una puntuación importante para los ciberdelincuentes que,
según el Director de Seguridad y Arquitectura de Keeper Security, bien capitalizado por
vender dicha información personal hasta $ 20 por pieza.
* Equifax es una de las agencias de informes crediticios más grandes de América del Norte.
315
Página 342
Otro ejemplo común en el que la información se ve directamente afectada es a través de virus informáticos.
Según el Informe de amenazas de McAfee Labs de diciembre de 2016, el número de ataques de malware
Aproximadamente 650 millones. Para los dispositivos móviles, el número de 2016 también es significativo, casi
acercándose a la marca de 13,5 millones. Además, en su informe de predicciones de amenazas de 2017, McAfee Labs
predice lo siguiente, entre otros:
◾ Los atacantes seguirán buscando oportunidades para romper las comunicaciones tradicionales (no móviles)
sistemas informáticos y aprovechar las vulnerabilidades. Los atacantes pueden explotar la información
sistemas cuyo firmware (software permanente programado en una memoria de solo lectura)
controla las operaciones de entrada y salida, o constituye unidades de estado sólido, red
tarjetas y dispositivos Wi-Fi. Es probable que estos tipos de exploits se muestren en común
ataques de malware.
◾ El ransomware en dispositivos móviles continuará su crecimiento aunque los atacantes probablemente
combinar estos ataques de bloqueo de dispositivos móviles con otros, como el robo de credenciales, que permiten
acceso a cuentas bancarias, tarjetas de crédito, etc.
Otros ejemplos de pérdidas de información sufridas por organizaciones son el resultado de fraude y
delitos (también conocidos como delitos de cuello blanco ). Según la Oficina Federal de Investigaciones
(FBI) Descripción general de los delitos de cuello blanco de 2017, el fraude corporativo sigue siendo uno de los principales
más prioridades criminales. El fraude corporativo da como resultado pérdidas financieras significativas para las empresas y
inversionistas, y continúan causando un daño inconmensurable a la economía estadounidense y la confianza de los inversion
dencia. El FBI afirma que la mayoría de los casos de fraude empresarial perseguidos involucran principalmente:
◾ Esquemas contables:
- Entradas contables falsas y / o tergiversaciones de la situación financiera;
- Operaciones fraudulentas diseñadas para inflar las ganancias u ocultar pérdidas; y
- Transacciones ilícitas diseñadas para evadir la supervisión regulatoria.
◾ Auto-trato por parte de ejecutivos corporativos y personas con información privilegiada:
- Uso de información privilegiada (comercio basado en información material no pública);
- Sobornos;
- Uso indebido de la propiedad corporativa para beneficio personal; y
- Infracciones fiscales individuales relacionadas con la autogestión.
Estos casos de fraude están diseñados para engañar a los inversores, auditores y analistas sobre la verdadera situación financ
condición de una corporación o entidad comercial. Mediante la manipulación de datos financieros, comparta
precio u otras medidas de valoración, el desempeño financiero de una corporación puede permanecer
inflado artificialmente sobre la base de indicadores de rendimiento ficticios proporcionados al público inversor.
Para agregar a lo anterior, en una Encuesta mundial sobre delitos económicos realizada por PricewaterhouseCoopers
LLP en 2014, las opiniones de más de 5,000 participantes de más de 100 países se presentaron en
la prevalencia y la dirección de los delitos económicos desde 2011. La encuesta reveló que el 54% de los
los participantes informaron que sus empresas experimentaron fraude de más de $ 100,000 con un 8% de informes
fraude de más de $ 5 millones.
Este capítulo habla sobre la importancia de la seguridad de la información para las organizaciones y
cómo la información representa un activo crítico en el entorno empresarial actual. Como puedas
Recordemos que la seguridad de la información es uno de los tres principales controles informáticos generales utilizados par
políticas y procedimientos de la organización relacionados con los sistemas de aplicación con el fin de respaldar el
funcionamiento eficaz de los controles de la aplicación. Ejemplos de controles generales dentro de la seguridad de la inform
Página 343
Seguridad de la información ◾ 317
abordar actividades tales como solicitudes de acceso y administración de cuentas de usuario; terminaciones de acceso;
y seguridad física. Este capítulo también analiza las tecnologías recientes que están revolucionando
organizaciones y, específicamente, la necesidad de una seguridad adecuada para proteger su información.
Las amenazas y riesgos de seguridad de la información, y cómo continúan afectando a los sistemas de información, son
también descrito. Estándares y pautas de seguridad de la información relevantes disponibles para las organizaciones.
Luego se discutirán las cuestiones y los auditores, junto con la importancia de una seguridad de la información.
política. Este capítulo continúa con una discusión de las funciones y responsabilidades de la seguridad de la información.
personal de la comunidad. Este capítulo termina con explicaciones de los controles de seguridad de la información, el signifi
cancelación de la selección, implementación y prueba de dichos controles, y la participación de la auditoría de TI en una
evaluación de la seguridad de la información.
La información representa un activo fundamental en muchas organizaciones en la actualidad. Sin confiable y adecuadamente
información segura, las organizaciones probablemente quebrarían. Sorprendentemente, aunque
Invertir en seguridad puede traerles muchos beneficios, ya que ayuda a proteger información valiosa.
activos y prevenir otras consecuencias devastadoras; muchas organizaciones no gastan lo suficiente en
gastos de seguridad. Según muchos jefes de seguridad, es muy difícil demostrar el valor
de inversiones en seguridad a menos que ocurra una catástrofe.
La preservación y mejora de la reputación de una organización está directamente relacionada con la forma en que
en el que se gestiona la información. Mantener un nivel adecuado de seguridad es uno de los varios
aspectos importantes de la gestión de la información y los sistemas de información. Los sistemas deben diseñarse
con seguridad para integrarse con la arquitectura de seguridad existente. La arquitectura de seguridad no es
un conjunto de productos. La arquitectura de seguridad es un modelo que especifica qué servicios, como autenticación
cation, autorización, auditoría y detección de intrusiones, deben ser abordados por tecnologías.
Proporciona un modelo con el que se pueden comparar las aplicaciones para responder preguntas como "¿Cómo
¿Están autenticados los usuarios? " Además, la arquitectura de seguridad ayuda a los desarrolladores a reconocer que
Los mismos servicios de seguridad son necesarios para muchas aplicaciones diferentes y esas aplicaciones deben
diseñado para el mismo modelo de seguridad.
La implementación efectiva de la seguridad de la información ayuda a garantizar que la estrategia de la organización
se cumplen los objetivos comerciales. Los tres objetivos fundamentales de la información son la confidencialidad,
integridad y disponibilidad. Estos objetivos se explican a continuación junto con los riesgos asociados que
impediría lograrlos.
◾ La confidencialidad es la protección de la información contra el acceso no autorizado. Esto es importante

en el mantenimiento de la imagen de la organización y en el cumplimiento de las leyes de privacidad. Un posible
El riesgo asociado con la confidencialidad incluye violaciones a la seguridad de la información que permiten
acceso no autorizado o divulgación de datos confidenciales o valiosos de la empresa (por ejemplo, el titular de la póli
información o planes estratégicos corporativos a la competencia o público, etc.).
◾ Integridad es la exactitud e integridad de la información. Esto es importante para mantener
la calidad de la información para la toma de decisiones. Un riesgo potencial asociado con la información
integridad incluye el acceso no autorizado a los sistemas de información, lo que resulta en
información y fraude o uso indebido de la información o los sistemas de la empresa.
◾ La disponibilidad se refiere al mantenimiento de los sistemas de información en apoyo de los procesos comerciales. Es
es importante para mantener la eficiencia y la eficacia operativas. Posibles riesgos asociados con
disponibilidad incluyen interrupción o falla de los sistemas de información, pérdida de la capacidad de procesar
Página 344
transacciones comerciales y colapso de los sistemas de información debido a fuentes como catástrofes,
virus o sabotaje.
Como ejemplo de la importancia de proteger la confidencialidad, integridad y disponibilidad

de información, el gobierno federal de los EE. UU. ha publicado Procesamiento de información federal
Estándares (FIPS) 200. FIPS 200 incluye requisitos mínimos de seguridad para proteger
sistemas de información general y la información procesada, almacenada y transmitida por aquellos
sistemas. Estos requisitos o áreas relacionadas con la seguridad incluyen (1) control de acceso; (2) consciente-
ness y formación; (3) auditoría y rendición de cuentas; (4) certificación, acreditación y seguridad
evaluaciones; (5) gestión de la configuración; (6) planificación de contingencias; (7) identificación y
autenticación; (8) respuesta a incidentes; (9) mantenimiento; (10) protección de los medios; (11) físico
y protección del medio ambiente; (12) planificación; (13) seguridad del personal; (14) evaluación de riesgos; (15)
adquisición de sistemas y servicios; (16) protección de sistemas y comunicaciones; y (17) sistema
e integridad de la información. Las 17 áreas representan una seguridad de la información equilibrada y de base amplia
programa que aborda los aspectos administrativos, operativos y técnicos de la protección de
sólo información federal y sistemas de información, pero también toda la información de interminables
amenazas y riesgos.
Seguridad de la información en el entorno de TI actual

La tecnología está en constante evolución y encuentra formas de dar forma al entorno de TI actual en el
organización. Las siguientes secciones describen brevemente las tecnologías recientes que ya han comenzado
para revolucionar las organizaciones, la forma de hacer negocios y la dinámica del lugar de trabajo. Con
estas tecnologías, es necesario que exista una seguridad adecuada para mitigar los riesgos y
proteger la información.
Planificación de recursos empresariales (ERP)

Según la edición de junio de 2016 de Apps Run the World, una empresa de investigación de mercado de tecnología
dedicado al espacio de aplicaciones, el mercado mundial de sistemas ERP alcanzará los $ 84,1 mil millones
para 2020 en comparación con $ 82.1 mil millones en 2015. ERP es un software que proporciona
funcionalidad en un sistema de entorno de TI integrado (por ejemplo, adquisiciones, inventario, contabilidad,
y recursos humanos). En esencia, los sistemas ERP permiten que múltiples funciones accedan a un
base de datos: reduciendo los costos de almacenamiento y aumentando la coherencia y precisión de los datos de una sola
fuente. Algunos de los principales proveedores de ERP en la actualidad incluyen SAP, FIS Global, Oracle, Fiserv, Intuit,
Inc., Cerner Corporation, Microsoft, Ericsson, Infor y McKesson.
A pesar de las muchas ventajas de los ERP, no son muy diferentes a los comprados o empaquetados.
sistemas y, por lo tanto, pueden requerir modificaciones importantes en procesos comerciales nuevos o existentes.
Las modificaciones de ERP (es decir, versiones de software) requieren una programación considerable para actualizar todos
código específico de la organización. Dado que los sistemas empaquetados son genéricos por naturaleza, las organizaciones
necesitan modificar sus operaciones comerciales para que coincidan con el método de procesamiento del proveedor, por ejem
Los cambios en las operaciones comerciales pueden no encajar bien en la cultura de la organización u otros procesos,
y también puede ser costoso debido a la capacitación. Además, como los ERP son ofrecidos por un solo proveedor, los riesg
asociado con tener un solo proveedor para aplicar (por ejemplo, dependiendo de un solo proveedor para el mantenimiento
y soporte, requisitos específicos de hardware o software, etc.).
Página 345
La computación en la nube sigue teniendo un impacto cada vez mayor en el entorno de TI. Computación en la nube
ha dado forma a negocios en todo el mundo, y algunas organizaciones lo utilizan para realizar negocios
procesos críticos. Según el informe de ISACA Innovation Insights de julio de 2015, la computación en la nube
considerada una de las tendencias clave que impulsa la estrategia empresarial. La Corporación Internacional de Datos, en
su publicación de 2015, también predice que la computación en la nube crecerá un 19,4% anual durante los próximos
5 años. Además, el informe de computación en la nube de la perspectiva 2016 de Deloitte indica que para
empresas, la computación en la nube seguirá siendo un factor dominante.
La computación en la nube, según la definición de PC Magazine, se refiere al uso de Internet (frente a la
disco duro de la computadora) para almacenar y acceder a datos y programas. De una manera más formal, el NIST
define la computación en la nube como un "modelo para permitir una red ubicua, conveniente y bajo demanda
acceso a un grupo compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento,
aplicaciones y servicios) que se pueden aprovisionar y lanzar rápidamente con una gestión mínima
esfuerzo o interacción del proveedor de servicios ". NIST también enfatiza que la disponibilidad se promueve significativam
por este modelo particular (nube).
Los servicios altamente flexibles que se pueden administrar en el entorno virtual hacen que la nube
informática muy atractiva para las organizaciones empresariales. No obstante, las organizaciones aún no se sienten
Totalmente cómodo al almacenar su información y aplicaciones en sistemas que residen en el exterior.
de sus instalaciones en el lugar. Migrar información a una infraestructura compartida (como una nube
medio ambiente) expone la información sensible / crítica de las organizaciones a riesgos de posibles
acceso y exposición personalizados, entre otros. Deloitte, una de las principales empresas mundiales de contabilidad y audito
ing empresas, también respalda la importancia de la seguridad y la privacidad anterior, y agregó, en función de su
Informe de computación en la nube de Perspective de 2016, esa información almacenada en la nube relacionada con los dato
Los datos bancarios y los registros de personal, por nombrar algunos, es vulnerable y susceptible de uso indebido si
caído en las manos equivocadas.
Gestión de dispositivos móviles (MDM)

MDM, también conocido como Enterprise Mobility Management, también está dando forma al entorno de TI en
organizaciones. MDM es responsable de gestionar y administrar dispositivos móviles (por ejemplo, smart-
teléfonos, computadoras portátiles, tabletas, impresoras móviles, etc.) proporcionados a los empleados como parte de su trab
posibilidades. En concreto, y según PC Magazine, MDM asegura estos dispositivos móviles:
◾ integrarse bien dentro de la organización y se implementan para cumplir con la organización

Policias y procedimientos
◾ proteger la información corporativa (por ejemplo, correos electrónicos, documentos corporativos, etc.) y la configuraci
configuración para todos los dispositivos móviles dentro de la organización
Los dispositivos móviles, también utilizados por los empleados por motivos personales, se pueden traer a la organización.
En otras palabras, los empleados pueden traer su propio dispositivo móvil a la organización (también
como traer-su-propio-dispositivo o BYOD) para realizar su trabajo. Permitir que los empleados utilicen
dispositivos móviles proporcionados por la organización por motivos laborales y personales ha demostrado ser atractivo para
empleado medio. Sin embargo, las organizaciones deben monitorear y controlar las tareas realizadas
por los empleados cuando utilizan dispositivos móviles, y garantizar que los empleados se mantengan enfocados y produzca
tivo. Representa un riesgo para la seguridad de la organización y una distracción para los empleados cuando
Los dispositivos móviles se utilizan para fines personales y laborales. Además, permitiendo el acceso directo a
Página 346
La información corporativa siempre representa un riesgo continuo, así como aumenta la seguridad y el cumplimiento.
preocupaciones de la organización.
Otros sistemas tecnológicos que afectan el entorno de TI

Internet de las cosas (IoT) tiene un efecto transformador potencial en los entornos de TI,
centros, proveedores de tecnología, etc. Un informe de Business Insider de 2016 indicó que habrá 34 mil millones
dispositivos conectados a Internet en 2020, frente a 10 mil millones en 2015. Además, los dispositivos de IoT
representan 24 mil millones de ellos, mientras que los dispositivos informáticos tradicionales (por ejemplo, teléfonos intelige
relojes inteligentes, etc.) comprenderá 10 mil millones. Y se gastarán casi 6 billones de dólares en IoT.
soluciones durante los próximos 5 años.
IoT, como lo define Gartner, Inc., es un sistema que permite activos remotos de "cosas"
(por ejemplo, dispositivos fijos o móviles, sensores, objetos, etc.) para interactuar y comunicarse entre ellos
y con otros sistemas de red. Los activos, por ejemplo, comunican información sobre su
estado, ubicación y funcionalidad, entre otros. Esta información no solo proporciona una mayor
comprensión precisa de los activos, pero maximiza su utilización y productividad, lo que resulta
en un proceso mejorado de toma de decisiones. Los enormes volúmenes de datos sin procesar o conjuntos de datos (también
como Big Data) generados como resultado de estas interacciones masivas entre dispositivos y sistemas
necesitan ser procesados y analizados de manera efectiva para generar información significativa
y útil en el proceso de toma de decisiones.
La industria está cambiando rápidamente y están madurando nuevos casos de uso de IoT. Cada vez hay más funcionalid
que se agrega a los sistemas de IoT para obtener las primeras ventajas en el mercado y beneficios funcionales, mientras que
de los dispositivos del sistema IoT a menudo se ignora durante el diseño. Esto es evidente en los hacks recientes:
◾ La Administración de Alimentos y Medicamentos de EE. UU. Emitió consejos de seguridad para dispositivos cardíaco
amenaza, y St. Jude Children's Research Hospital parcheó los dispositivos médicos vulnerables de IoT.
◾ Los piratas informáticos demostraron un ataque inalámbrico en el automóvil Tesla Model S.
◾ Los investigadores piratearon televisores inteligentes Vizio para acceder a una red doméstica.
Otras fuentes de oportunidades de seguridad perdidas ocurren durante la instalación y posterior a la instalación de IoT
configuración. Una encuesta de seguridad de ForeScout IoT indicó que "los encuestados, que inicialmente pensaron
no tenían dispositivos IoT en sus redes, en realidad tenían ocho tipos de dispositivos IoT (cuando se les preguntó
para elegir de una lista de dispositivos) y solo el 44% de los encuestados tenía una política de seguridad conocida para
IoT ". Solo el 30% confía en saber realmente qué dispositivos de IoT hay en su red. Estas
hacks y las implicaciones de los resultados de la encuesta de ForeScout indican que la seguridad de IoT debe ser
implementado de manera integral.
Big Data, según la definición de la Comisión Federal de Big Data de la TechAmerica Foundation (2012),
“Describe grandes volúmenes de datos variables, complejos y de alta velocidad que requieren
técnicas y tecnologías para permitir la captura, almacenamiento, distribución, gestión y análisis
de la información ". Gartner, Inc. lo define además como "... alto volumen, alta velocidad y / o alta
una variedad de activos de información que exigen formas innovadoras y rentables de procesamiento de información
que permiten una mejor comprensión, toma de decisiones y automatización de procesos ".
Aunque Big Data preciso puede conducir a un proceso de toma de decisiones más seguro, y
Las mejores decisiones a menudo dan como resultado una mayor eficiencia operativa, reducción de costos y reducción del ri
Actualmente existen desafíos que deben abordarse. Los desafíos de Big Data incluyen, por ejemplo,
análisis, captura, conservación de datos, búsqueda, uso compartido, almacenamiento, transferencia, visualización, consulta, t
como actualización. Ernst and Young, en la publicación de septiembre de 2015 de su EY Center for Board Matters,
Página 347
establece que los desafíos para los auditores incluyen el acceso limitado a los datos relevantes de auditoría; escasez de
personal disponible y calificado para procesar y analizar tales datos particulares; y el oportuno
integración de la analítica en la auditoría.
Otras tecnologías emergentes recientes que actualmente están impactando los entornos de TI incluyen
dispositivos portátiles (por ejemplo, relojes inteligentes, etc.), impresión 3D para el consumidor, vehículos autónomos, cripto
blockchain y traducción de voz a voz, entre otros.
Amenazas y riesgos de seguridad de la información

La expansión del uso de computadoras ha resultado en graves abusos de los sistemas de comunicación de datos. Computado
los piratas informáticos y, a veces, los empleados utilizan el sistema de comunicaciones de datos de una organización para m
con los datos de la organización, destruyendo información, introduciendo registros fraudulentos y robando
ing activos con el toque de algunas teclas. Las primeras apariciones de esta vulnerabilidad aparecieron en 1981.
Un gran jurado de Pensilvania acusó a nueve estudiantes (de entre 17 y 22 años) de usar computadoras y
servicios telefónicos privados para realizar llamadas ilegales de larga distancia y recibir mercancías
tres envíos de correo en el área de Filadelfia sin recibir factura. Durante un período de 6 meses, el grupo
fue responsable de $ 212,000 en robo de servicios y $ 100,000 en mercadería robada.
Varias décadas después, los métodos se han vuelto más sofisticados y las vulnerabilidades
continue a existir. Por ejemplo, el 8 de noviembre de 2008, se produjo una serie de robos en todo el mundo.
casi simultáneamente. Más de 2.100 máquinas de hacer dinero en al menos 280 ciudades en tres continentes en
países como EE.UU., Canadá, Italia, Hong Kong, Japón, Estonia, Rusia y Ucrania fueron
comprometidos. En 12 horas, los ladrones, liderados por cuatro piratas informáticos, robaron un total de más de $ 9.
millones en efectivo. La única razón por la que cesó el robo fue porque los cajeros automáticos se habían quedado sin dinero
fue uno de los ataques de fraude informático más sofisticados y organizados jamás realizados.
Según el Informe sobre delitos en Internet de 2016, el Centro de quejas sobre delitos en Internet del FBI
(IC3) recibió un total de 298,728 quejas con pérdidas reportadas superiores a $ 1.3 mil millones. En
2015, el FBI recibió 127,145 quejas de un total de 288,012 sobre sospechas de Internet
facilitó la actividad delictiva que en realidad informó haber experimentado una pérdida. Pérdidas totales reportadas
en 2015 ascendió a $ 1,070,711,522 (o casi un 134% de aumento con respecto a la pérdida total reportada de 2014
de $ 800,492,073). En 2014, se recibieron 123.684 denuncias (de un total de 269.422) por
el FBI que en realidad informó una pérdida por actividad delictiva en línea. En 2015, la mayoría de los
Las quejas recibidas por el FBI involucraban a criminales que hospedaban servicios gubernamentales fraudulentos.
Sitios web para adquirir información de identificación personal y cobrar tarifas fraudulentas de
consumidores. Otros notables entre 2014 y 2016 involucraron "impago" (es decir,
bienes / servicios enviados o proporcionados, pero pago nunca prestado); "No entrega" (es decir, pago
enviado, pero bienes / servicios nunca recibidos); el robo de identidad; violación de datos personales; extorsión; imper-
sonación; y otros. Algunos de los delitos de Internet denunciados con más frecuencia desde 2014 hasta
2016 se enumeran en el Anexo 2.1 del Capítulo 2. Técnicas conocidas, según Malware Labs '
Las tácticas y técnicas de ciberdelincuencia para el primer trimestre de 2017, para cometer delitos cibernéticos, incluyen ma
somware, estafas en redes sociales y estafas de soporte técnico. Otras técnicas de uso común para comparar
mit estos ciberdelitos se muestran en el Anexo 12.1.
El FBI también ha identificado múltiples fuentes de amenazas a las infraestructuras críticas de nuestra nación,
incluyendo naciones extranjeras involucradas en la guerra de información, criminales domésticos, hackers y
terroristas, junto con empleados descontentos que trabajan dentro de una organización. Estos se muestran en
Figura 12.2. El Centro del Equipo de Preparación para Emergencias Informáticas (CERT) también ha sido informado:
aumentando la actividad en las vulnerabilidades.
Página 348
Figura 12.1 Técnicas utilizadas para cometer delitos cibernéticos
Spam Mensajes en línea disruptivos, especialmente mensajes comerciales publicados en

una red informática o enviado como correo electrónico.
Suplantación de identidad Una estafa de alta tecnología que frecuentemente usa spam o mensajes emergentes para
engañar a las personas para que revelen su información personal (es decir, crédito
números de tarjetas, información de cuentas bancarias, números de seguro social,
contraseñas u otra información confidencial). Los estafadores de Internet utilizan
cebo de correo electrónico para "phish" en busca de contraseñas y datos financieros del mar de
Usuarios de Internet.
Spoofing Crear un sitio web fraudulento para imitar un sitio web real y conocido
dirigido por otra parte. La suplantación de correo electrónico se produce cuando la dirección del remitente
y otras partes del encabezado de un correo electrónico se modifican para que parezcan
el correo electrónico se originó en una fuente diferente. La suplantación oculta el
origen de un mensaje de correo electrónico.
Pharming Un método utilizado por los phishers para engañar a los usuarios haciéndoles creer que
se están comunicando con un sitio web legítimo. Pharming utiliza un
variedad de métodos técnicos para redirigir a un usuario a un fraudulento o
Sitio web falsificado cuando el usuario escribe una dirección web legítima.
Por ejemplo, una técnica de pharming es redirigir a los usuarios, sin
su conocimiento, a un sitio web diferente al que pretendían
acceder. Además, las vulnerabilidades de software pueden ser explotadas o malware.
empleado para redirigir al usuario a un sitio web fraudulento cuando el usuario
escribe una dirección legítima.
Negación de servicio Ataque diseñado para desactivar una red inundándola de tráfico inútil.
ataque
Repartido Una variante del ataque de denegación de servicio que utiliza un ataque coordinado
negación de servicio de un sistema distribuido de computadoras en lugar de un solo
fuente. A menudo utiliza gusanos para propagarse a varios equipos.
que luego puede atacar al objetivo.
Virus Pieza de código de programa que contiene lógica de autorreproducción, que

se suma a otros programas y no puede sobrevivir por sí solo.
caballo de Troya Pieza de código dentro de un programa que causa daño al destruir datos
u obtener información.
Gusano Código de programa independiente que se replica a sí mismo y devora los datos,
consume memoria y ralentiza el procesamiento.
Software malicioso Código malicioso que se infiltra en una computadora. Es un software intrusivo con
el propósito de dañar o deshabilitar computadoras y computadoras
sistemas.
Software espía Malware instalado sin el conocimiento del usuario para rastrear subrepticiamente
y / o transmitir datos a un tercero no autorizado.
( Continuacion )
Página 349
Figura 12.1 ( continuación ) Técnicas utilizadas para cometer delitos informáticos
Botnet Una red de sistemas controlados de forma remota que se utiliza para coordinar ataques.
y distribuir estafas de malware, spam y phishing. Bots (abreviatura de
"Robots") son programas que se instalan de forma encubierta en un sistema de destino
permitir que un usuario no autorizado controle de forma remota el
computadora para una variedad de propósitos maliciosos.
Adaptado de la Oficina de Contabilidad General de los Estados Unidos, CYBERCRIME — Public and Private
Entities Face Challenges in Addressing Cyber Threats, GAO-07-705, 22 de junio de 2007.
Figura 12.2 Fuentes de amenazas cibernéticas a la infraestructura crítica de EE. UU.

Observado por el FBI
Fuente de amenaza Descripción
Grupos criminales Grupos de personas o entidades que atacan los sistemas de información para
ganancia monetaria. Hay un mayor uso de intrusiones cibernéticas por
grupos criminales.
Estados nacionales extranjeros Los servicios de inteligencia extranjeros utilizan herramientas cibernéticas como parte de su
actividades de recopilación de información y espionaje. Además, varios
las naciones están trabajando agresivamente para desarrollar la guerra de la información
doctrina, programas y capacidades. Tales capacidades permiten
entidad única para tener un impacto significativo y serio al interrumpir
las infraestructuras de suministro, comunicaciones y económicas que
apoyar el poder militar: impactos que, según el director de
la Agencia Central de Inteligencia, puede afectar la vida diaria de
Estadounidenses en todo el país.
Hackers Los piratas informáticos a veces entran en las redes por la emoción de la
desafío o por los derechos de fanfarronear en la comunidad de hackers. Mientras
el craqueo remoto alguna vez requirió una buena cantidad de habilidad o computadora
conocimiento, los hackers ahora pueden descargar scripts de ataque y
protocolos de Internet y lanzarlos contra los sitios de las víctimas.
Por lo tanto, las herramientas de ataque se han vuelto más sofisticadas y
más fácil de usar.
Hacktivistas El hacktivismo se refiere a ataques por motivos políticos contra

páginas web accesibles o servidores de correo electrónico. Estos grupos y
las personas sobrecargan los servidores de correo electrónico y piratean los sitios web para enviar
un mensaje político.
Insatisfechos con información privilegiada

El insider descontento, que trabaja desde dentro de una organización, es un
fuente principal de delitos informáticos. Los iniciados pueden no necesitar una gran
gran cantidad de conocimientos sobre intrusiones informáticas porque su
El conocimiento de un sistema de víctimas a menudo les permite ganar
acceso sin restricciones para causar daños al sistema o para robar
datos de sistema. La amenaza interna también incluye al personal de los contratistas.
( Continuacion )
Página 350
Figura 12.2 ( continuación ) Fuentes de amenazas cibernéticas a la infraestructura crítica de EE. UU.
Observado por el FBI
Fuente de amenaza Descripción
Terroristas Los terroristas buscan destruir, incapacitar o explotar

infraestructuras que amenacen la seguridad nacional, causen bajas masivas,
debilitar la economía de Estados Unidos y dañar la moral pública y
confianza. Sin embargo, los adversarios terroristas de los EE. UU.
desarrollado en sus capacidades de red informática que otros
adversarios. Es probable que los terroristas representen una amenaza cibernética limitada. los
La Agencia Central de Inteligencia cree que los terroristas se mantendrán enfocados en
métodos de ataque tradicionales, pero anticipa crecientes amenazas cibernéticas
a medida que una generación técnicamente más competente ingresa a las filas.
Adaptado de la Oficina de contabilidad general de los Estados Unidos, Seguridad de la información: TVA necesita
Abordar las debilidades en los sistemas y redes de control , GAO-08-526, 21 de mayo de 2008.
Junto con estas crecientes amenazas, la cantidad de vulnerabilidades de seguridad informática informadas
a la base de datos nacional de vulnerabilidades del NIST ha alcanzado más de 89,700 vulnerabilidades en agosto de 2017.
Según un informe de la Oficina de Contabilidad del Gobierno (GAO), el director del Centro CERT
afirmó que hasta el 80% de los incidentes de seguridad reales no se denuncian en la mayoría de los casos porque
organización (1) no pudo reconocer que sus sistemas habían sido penetrados porque no había
indicación de penetración o ataque o (2) se mostró reacio a informar los incidentes.
Dado que tanto los gobiernos como las empresas de todo el mundo confían cada vez más en
sistemas y datos electrónicos, se está produciendo un aumento correspondiente de riesgos de fraude,
divulgación de datos confidenciales e interrupción de operaciones y servicios críticos, entre otros. los
Los mismos factores que benefician a las operaciones comerciales y gubernamentales también hacen posible que las persona
y organizaciones para interferir de forma económica o escuchar a escondidas estas operaciones desde
ubicaciones con fines de fraude o sabotaje, u otros fines maliciosos o maliciosos.
Estándares de seguridad de la información

Los estándares y directrices de seguridad de la información proporcionan un marco para implementar
exhaustivos procesos y controles de seguridad. Tres informaciones sobre mejores prácticas ampliamente reconocidas
Los estándares de seguridad incluyen: COBIT de ISACA, la Organización Internacional de Estándares Británicos para
Normalización (ISO) / Comisión Electrotécnica Internacional 27002 (ISO / IEC 27002), y
el Instituto Nacional de Estándares y Tecnología (NIST). Estos estándares proporcionan a la organización
relaciones con los medios para abordar diferentes ángulos dentro del campo de la seguridad de la información.
COBIT
COBIT ayuda a las organizaciones a enfrentar los desafíos comerciales actuales en las áreas de seguridad de la información,
cumplimiento normativo, gestión de riesgos y alineación de la estrategia de TI con la organización
metas, entre otras. COBIT es un conjunto internacional autorizado de TI generalmente aceptado
estándares, prácticas u objetivos de control diseñados para ayudar a los empleados, gerentes, ejecutivos,
y auditores en: entender los sistemas de TI, cumplir con las responsabilidades fiduciarias y decidir
niveles adecuados de seguridad y controles.
Página 351
COBIT apoya la necesidad de investigar, desarrollar, publicitar y promover la internacionalización actualizada.

objetivos de control de TI totalmente aceptados. El énfasis principal de COBIT es garantizar que la tecnología
proporciona a las empresas información relevante, oportuna y de calidad para la toma de decisiones.
COBIT, ahora en su quinta edición (COBIT 5), permite a la gerencia comparar su TI / seguridad
medio ambiente y compararlo con otras organizaciones. Los auditores de TI también pueden usar COBIT para respaldar
tificar sus evaluaciones y opiniones de control interno. Debido a que el estándar es completo,
proporciona garantías de que existen controles y seguridad de TI.
COBIT 5 ayuda a las organizaciones a crear un valor óptimo de TI manteniendo un equilibrio entre
obteniendo beneficios y optimizando los niveles de riesgo y el uso de recursos. COBIT 5 se basa en cinco principios.
Considera las necesidades de TI / seguridad de las partes interesadas internas y externas (Principio 1), mientras
cubriendo el gobierno y la gestión de la información y la tecnología relacionada de la organización
(Principio 2). COBIT 5 proporciona un marco integrado que se alinea e integra fácilmente con
otros marcos (por ejemplo, Comité de Organizaciones Patrocinadoras de la Comisión Treadway-
Gestión de Riesgos Empresariales (COSO-ERM), etc.), estándares y mejores prácticas utilizadas (Principio 3).
COBIT 5 permite que la TI sea gobernada y administrada de manera holística para toda la organización.
(Principio 4). Por último, ayuda a las organizaciones a separar adecuadamente la gobernanza de la gestión.
objetivos de desarrollo (Principio 5).
COBIT es valioso para organizaciones de todos los tamaños, incluidas las comerciales, sin fines de lucro o en
el sector público. El estándar integral proporciona un conjunto de objetivos de control de seguridad y de TI
Auditores de TI en su búsqueda por examinar esos objetivos.
ISO / IEC 27002

ISO / IEC 27002 es un estándar global (utilizado junto con ISO / IEC 27001) que proporciona la mejor
recomendaciones prácticas relacionadas con la gestión de la seguridad de la información. El estandar
se aplica a los encargados de iniciar, implementar y / o mantener la seguridad de la información
sistemas de gestión. Este estándar también ayuda a implementar información comúnmente aceptada
controles y procedimientos de seguridad (ISC).
ISO / IEC 27002 es el cambio de nombre de la norma ISO 17799 y es un código de prácticas para la información.
seguridad. Describe cientos de posibles controles y mecanismos de control en las secciones principales.
como la evaluación de riesgos; politica de seguridad; gestión de activos; seguridad de los recursos humanos; físico
y seguridad ambiental; control de acceso; adquisición, desarrollo y desarrollo de sistemas de información
mantenimiento; gestión de incidentes de seguridad de la información; gestión de la continuidad del negocio; y
conformidad. La base del estándar fue originalmente un documento publicado por el gobierno del Reino Unido.
ment, que se convirtió en un estándar "adecuado" en 1995, cuando fue reeditado por BSI como BS7799.
En 2000, se volvió a publicar, esta vez por ISO / IEC, como ISO / IEC 17799. Una nueva versión de
apareció en 2005, junto con una nueva publicación, ISO / IEC 27001. Estos dos documentos son
destinados a ser utilizados juntos, uno complementando al otro.
El kit de herramientas ISO / IEC 27000 es el principal recurso de soporte para ISO / IEC 27001 e ISO /
Normas IEC 27002. Contiene una serie de elementos diseñados específicamente para ayudar con la implementación
mentación y auditoría. Éstas incluyen:
◾ Copia de la propia ISO / IEC 27001

◾ Copia de ISO / IEC 27002 en sí
◾ Cuestionario completo de evaluación de impacto empresarial (BIA)
◾ Guía / hoja de ruta de certificación
Página 352
◾ Lista de verificación de auditoría de red

◾ Conjunto completo de políticas de seguridad de la información alineadas con ISO / IEC 27002
◾ Equipo de recuperación ante desastres, que incluye lista de verificación y cuestionario
◾ Presentación de la gerencia para enmarcar el contexto de los estándares
◾ Glosario de términos y frases de SI y TI
Una empresa con certificación ISO / IEC 27002 podría ganar negocios sobre competidores que no
certificado. Si un cliente potencial elige entre dos servicios diferentes y la seguridad es una
preocupación, generalmente irán con la opción certificada. Además, una empresa certificada realizará:
◾ Seguridad empresarial mejorada

◾ Planificación y gestión de la seguridad más eficaces
◾ Asociaciones y comercio electrónico más seguros
◾ Mayor confianza del cliente
◾ Auditorías de seguridad más precisas y fiables
◾ Responsabilidad reducida
El marco ISO / IEC 27002 promueve la seguridad de la información sólida en las organizaciones ya que:
◾ incluye ISC para ayudar a las organizaciones a cumplir con los requisitos legales, reglamentarios y contractuales.
requisitos, así como con las políticas, principios, estándares y /
u objetivos (ISO / IEC 27002, 2005).
◾ está diseñado para abordar los aspectos de confidencialidad, integridad y disponibilidad de los sistemas de TI
dentro de las organizaciones.
◾ define las pautas fundamentales para garantizar una seguridad de la información adecuada y sólida en
la organización. Las mejores prácticas comunes de ISO / IEC 27002 ofrecen procedimientos y métodos,
probado en la práctica, que podría adaptarse a los requisitos específicos de la empresa.
◾ cubre todo tipo de organizaciones (por ejemplo, comerciales, gubernamentales, sin fines de lucro, etc.).
◾ se basa en un enfoque de sistemas de gestión y representa una opción viable de muchas
organizaciones para desarrollar programas de seguridad de la información.
La familia de normas ISO / IEC 27000 incluye técnicas que ayudan a las organizaciones a asegurar sus
activos de información. Algunos estándares, además de los mencionados anteriormente, involucran seguridad de TI
técnicas relacionadas con:
◾ Requisitos para establecer, implementar, mantener, evaluar y continuamente

Mejorar un sistema de gestión de seguridad de la información dentro del contexto de la organización.
ción. Estos requisitos son genéricos y están destinados a ser aplicables a todas las organizaciones,
independientemente del tipo, tamaño o naturaleza. (ISO / IEC 27001: 2013)
◾ Orientación para la implementación del sistema de gestión de seguridad de la información. (ISO / IEC DIS
27003)
◾ Pautas para implementar la gestión de la seguridad de la información (es decir, iniciar, implementar
mantenimiento y mejora de la seguridad de la información) para las organizaciones intersectoriales e interorganizacio
Comunicaciones (ISO / IEC 27010: 2015)
◾ Orientación
como se especifica
sobre la en ISO / IEC 27001,
implementación y un sistema
integrada de gestión
de un sistema de servicios,
de gestión como se
de seguridad deespecifica en ISO / IEC
la información,
20000-1 (ISO / IEC 27013: 2015).
Página 353
La familia de estándares ayuda a las organizaciones a administrar la seguridad de los activos, incluidos, pero no
limitado a, información financiera, propiedad intelectual, detalles de los empleados o información confiada
por terceros.
NIST
Un enfoque principal de las actividades del NIST en TI es proporcionar criterios de medición para respaldar la
desarrollo de tecnología fundamental y con visión de futuro. Los estándares y pautas del NIST se publican como
Estándares federales de procesamiento de información (FIPS) para uso en todo el gobierno. NIST desarrolla FIPS
cuando existen requisitos imperiosos del gobierno federal para los estándares de TI relacionados con la seguridad
e interoperabilidad, y no existen estándares o soluciones industriales aceptables.
Una de las primeras de varias normas federales emitidas por NIST en 1974 fue FIPS 31, “Pautas para
Procesamiento automático de datos Seguridad física y gestión de riesgos ”. Esta norma proporcionó
orientación inicial a las organizaciones federales en el desarrollo de programas de gestión de riesgos y seguridad física
gramos para las instalaciones del sistema de información. Luego, en marzo de 2006, NIST emitió FIPS 200 "Mínimo
Requisitos de seguridad para la información y los sistemas de información federales ”, donde las agencias federales
fueron responsables de incluir dentro de su información “políticas y procedimientos que aseguren el cumplimiento
con requisitos de configuración del sistema mínimamente aceptables, según lo determine la agencia ".
La gestión de las configuraciones del sistema también es un requisito mínimo de seguridad identificado en FIPS 200
y NIST SP 800–53, “Controles de seguridad y privacidad para sistemas de información federales y
Organizaciones ”, llegó a definir los controles de seguridad y privacidad que respaldaban este requisito.
En agosto de 2011, NIST publicó SP 800-128, “Guía para la configuración centrada en la seguridad
Gestión de SI ". Conceptos y principios de gestión de la configuración descritos en este especial
La publicación proporcionó información de respaldo para NIST SP 800–53, y cumplió con los
Management Framework (RMF) que se analiza en NIST SP 800-37, “Guía para aplicar la
Marco de gestión de riesgos para los sistemas de información federales: un enfoque de ciclo de vida de seguridad ”,
según enmendado. Directrices más específicas sobre la implementación del paso de seguimiento del MGR
se proporcionan en NIST SP 800-137, “Monitoreo continuo de seguridad de la información para
SI y Organizaciones ". El propósito del NIST SP 800-137 en el RMF es continuamente
monitorear la efectividad de todos los controles de seguridad seleccionados, implementados y autorizados para
proteger la información organizacional y los sistemas de información, que incluye la configuración
controles de seguridad de gestión identificados en SP 800–53. Estos documentos son un muy buen comienzo
punto para comprender la base y muchos enfoques que se pueden usar para evaluar el riesgo en TI hoy.
Al evaluar los riesgos relacionados con la TI, se debe prestar especial atención al NIST SP
Guía 800-30, "Guía para realizar evaluaciones de riesgos". * La guía NIST SP 800-30 proporciona
una base común para el personal de las organizaciones con o sin experiencia, que utilizan
o apoyar el proceso de gestión de riesgos para sus sistemas de TI. El personal de las organizaciones incluye:
alta gerencia, gerentes de seguridad de TI, personal de soporte técnico, consultores de TI y TI
auditores, entre otros. El estándar de evaluación de riesgos del NIST SP 800-30 se puede implementar en
sistemas interrelacionados únicos o múltiples, desde pequeñas a grandes organizaciones.
Las pautas del NIST han ayudado a las agencias y organizaciones federales a mejorar significativamente
su calidad general de seguridad de TI mediante:
◾ proporcionar un marco estándar para gestionar y evaluar la información de las organizaciones

riesgos de sistemas, al mismo tiempo que respalda las misiones organizacionales y las funciones comerciales;
Página 354
◾ permitir la toma de determinaciones basadas en el riesgo, garantizando al mismo tiempo implementaciones rentables;
◾ describir un enfoque más flexible y dinámico que se puede utilizar para monitorear
estado de seguridad de la información de los sistemas de información de las organizaciones;
◾ apoyar un enfoque de abajo hacia arriba en lo que respecta a la seguridad de la información, centrado en
sistemas de información que apoyan a la organización; y
◾ promover un enfoque de arriba hacia abajo relacionado con la seguridad de la información, centrándose en
Problemas relacionados con las TI desde una perspectiva corporativa.
Las organizaciones dentro del sector privado utilizan las pautas del NIST para promover negocios críticos seguros.
funciones, incluida la confianza de los clientes en la capacidad de las organizaciones para proteger sus
e información sensible. Además, la flexibilidad de implementar las pautas del NIST proporciona
organizaciones herramientas apropiadas para demostrar el cumplimiento de las regulaciones.
Otras fuentes de estándares de seguridad de la información incluyen la conocida Información
Biblioteca de infraestructura tecnológica (ITIL), Estándar de seguridad de datos de la industria de tarjetas de pago (PCI
DSS) y los marcos de Cloud Security Alliance (CSA). El propósito del estándar ITIL, para
ejemplo, es centrarse en alinear los servicios de TI con las necesidades de las organizaciones empresariales. Específicamente
ITIL define la estructura organizativa, los requisitos de habilidades y un conjunto de estándares operativos
procedimientos y prácticas de gestión que permitan a la organización establecer una línea de base a partir de la cual
puede planificar, implementar, administrar y medir una operación de TI y la infraestructura asociada.
ITIL se utiliza principalmente para demostrar el cumplimiento y medir la mejora.
PCI DSS se refiere a los requisitos técnicos y operativos aplicables a las entidades que almacenan, procesan,
o transmitir datos del titular de la tarjeta, con la intención de proteger dichos datos con el fin de reducir la tarjeta de crédito
fraude. Las PCI DSS son mantenidas, administradas y promovidas por el PCI Security Standards Council
(Consejo) en todo el mundo para proteger los datos de los titulares de tarjetas. El Consejo fue fundado en 2006 por importan
empresas de tarjetas, como American Express, Discover, JCB International, MasterCard y Visa, Inc.
Estas empresas comparten por igual en la gobernanza, ejecución y cumplimiento del trabajo del Consejo.
Cloud Security Alliance se define como “la organización líder mundial dedicada a definir
y concienciar sobre las mejores prácticas para ayudar a garantizar un entorno de computación en la nube seguro ". *
Entre otros, CSA ofrece:
◾ investigación, educación, certificación y productos específicos de seguridad en la nube.

◾ actividades de networking para toda la comunidad afectada por la nube, incluidos proveedores, clientes,
gobiernos, empresarios y la industria de aseguramiento.
◾ foros a través de los cuales las diversas partes pueden trabajar juntas para crear y mantener un
ecosistema de nube.
◾ un programa de certificación de proveedores de seguridad en la nube (es decir, CSA Security, Trust & Assurance
Registro (STAR)). CSA-STAR es un programa de garantía de proveedores de tres niveles de
evaluación, auditoría de terceros y seguimiento continuo.
◾ eventos educativos de alta calidad en todo el mundo y en línea.
Política de seguridad de la información

Según el Instituto SANS, el término política generalmente se refiere a un documento (o conjunto de documentos
mentos) que resume las reglas y requisitos que generalmente son específicos de un punto, deben cumplirse, y
* https://cloudsecurityalliance.org/about/.
Página 355
cubrir una sola área. Una política del sistema de información de "uso aceptable", por ejemplo, cubre reglas para
uso apropiado del sistema de información y las instalaciones informáticas. Una póliza difiere de un estándar
o una pauta. Una norma se refiere a una colección de requisitos específicos del sistema o de procedimientos específicos.
que hacen cumplir una política determinada. Los estándares se establecen por autoridad, costumbre o consentimiento genera
un modelo o ejemplo, y su cumplimiento es obligatorio. Un ejemplo de estándar sería el
Especificación de requisitos mínimos de contraseña (por ejemplo, las contraseñas deben tener al menos ocho caracteres
de longitud, y requieren al menos un número y un carácter especial, etc.) que deben configurarse
por todos los usuarios con el fin de mejorar la seguridad informática. El estándar mencionado ayuda a hacer cumplir el
cumplimiento con una "Política de contraseñas", por ejemplo. Un estándar también puede tener la forma de una tecnología
selección (por ejemplo, selección de una tecnología particular para el monitoreo continuo de seguridad, etc.) que
cumple con una política específica. Las directrices, por otro lado, también son específicas del sistema o de procedimientos.
específico; sin embargo, son "sugerencias" para las mejores prácticas. En otras palabras, no se refieren a reglas o
requisitos que deben cumplirse, pero hay que tener en cuenta recomendaciones sólidas. Una seguridad de la información efic
La política hace frecuentes referencias a estándares y directrices que existen dentro de una organización.
Una política de seguridad de la información define las prácticas de seguridad que se alinean con la estrategia
objetivos de la organización. Describe formas de prevenir y responder a una variedad de amenazas.
a la información y los sistemas de información, incluido el acceso no autorizado, la divulgación, la duplicación,
modificación, apropiación, destrucción, pérdida, mal uso y denegación de uso. La seguridad de la información
La política está destinada a guiar a la administración, los usuarios y los diseñadores de sistemas en la toma de decisiones sob
seguridad de información. Proporciona declaraciones de alto nivel de metas, objetivos,
creencias, ética, controles y responsabilidades.
Un factor importante para implementar una política de seguridad de la información en una organización es hacer
una evaluación de las necesidades de seguridad. Esto se logra entendiendo primero el negocio de la organización.
necesidades y, en segundo lugar, estableciendo objetivos de seguridad. Hay algunas preguntas comunes que deben responder
◾ ¿Qué información es fundamental para el negocio?

◾ ¿Quién crea esa información crítica?
◾ ¿Quién usa esa información?
◾ ¿Qué sucedería si se roba, corrompe o pierde información crítica?
◾ ¿Cuánto tiempo puede operar la empresa sin acceso a información crítica?
La seguridad de la información atraviesa múltiples áreas. La política de seguridad de la información debe estar coordinada
con desarrollo de sistemas, control de cambios, recuperación ante desastres, cumplimiento y recursos humanos
políticas para garantizar la coherencia. Una política de seguridad de la información debe indicar el uso de la Web y el correo
ética y discutir las limitaciones de acceso, la política de confidencialidad y cualquier otro problema de seguridad. Bueno
Las políticas brindan a los empleados instrucciones precisas sobre cómo se manejan los eventos y cómo se escala la recupera
necesario. La política debe estar disponible y distribuida a todos los usuarios dentro de la organización.
El Instituto SANS tiene varias plantillas de políticas de seguridad de la información disponibles para más de 25
requerimientos de seguridad. * Estos sirven como un gran punto de partida para un rápido desarrollo e implementación.
de las políticas de seguridad de la información. El Instituto ha desarrollado plantillas de políticas de seguridad de la informa
y los clasificó en las siguientes categorías: General, Seguridad de red, Seguridad del servidor y
Seguridad de la aplicación. A continuación, se muestran algunas de las áreas de plantilla de políticas que ofrece cada categor
◾ General: incluye plantillas de políticas de seguridad de la información que cubren las áreas de: Aceptable
Política de cifrado, Política de uso aceptable, Política de escritorio limpio, Política de respuesta a la violación de dato
* https://www.sans.org/security-resources/policies/#template.
Página 356
Política del plan de recuperación ante desastres, Política de aceptación de firma digital, Política de correo electrónico
Política de planificación de respuesta ante una pandemia, pautas de construcción de contraseñas, protección con contr
Política, Política del plan de respuesta de seguridad y Política de protección de la clave de cifrado del usuario final.
◾ Seguridad de la red: incluye plantillas de políticas de seguridad de la información que cubren las áreas
de: Política de evaluación de adquisiciones, Política de requisitos básicos de Bluetooth, Control remoto
Política de acceso, Política de herramientas de acceso remoto, Política de seguridad de conmutadores y enrutadores, C
Política de comunicación y estándar de comunicación inalámbrica.
◾ Seguridad del servidor: incluye plantillas de políticas de seguridad de la información que cubren las áreas de:
Política de credenciales de base de datos, Política de eliminación de equipos tecnológicos, Registro de información
Estándar, Política de seguridad de laboratorio, Política de seguridad del servidor, Política de instalación de software y
Política de seguridad de la estación de trabajo (para HIPAA).
◾ Seguridad de aplicaciones: incluye plantillas de políticas de seguridad de la información que cubren el área de
Política de seguridad de aplicaciones web.
Designaciones de clasificación de información

Las políticas de seguridad de la información también son útiles para las organizaciones cuando documentan información.
requisitos de designación de clasificación. Las organizaciones necesitan establecer una clasificación de información
sistema que categoriza la información en agrupaciones. Los grupos de información ayudan a determinar cómo
la información debe estar protegida. En el sector privado, puede haber razones legales o reglamentarias para clasificar
clasificar la información en público, interno o confidencial. En el sector gubernamental, también puede haber
razones de seguridad nacional para clasificar la información en varias categorías (por ejemplo, alto secreto, etc.).
Si la información es sensible, desde que se crea hasta que se destruye o desclasifica,
debe estar etiquetado (marcado) con una designación de clasificación de información apropiada. Tal
Las marcas deben aparecer en todas las manifestaciones de la información (copias impresas, medios externos, etc.).
La gran mayoría de la información pertenece a la categoría Solo para uso interno. Por esta razón, es
No es necesario aplicar una etiqueta a la información de uso interno únicamente. La información sin etiqueta es
por lo tanto, se clasifica de forma predeterminada como Sólo para uso interno.
El acceso a la información en posesión o bajo el control de la organización debe
proporcionarse en función de la necesidad de saber. En otras palabras, la información debe revelarse solo a
personas que tienen una necesidad legítima de la información. Al mismo tiempo, los usuarios no deben retener
acceso a la información cuando el propietario de la información en cuestión instruya que sea compartida.
Para implementar el concepto de necesidad de saber, las organizaciones deben adoptar una solicitud de acceso y un propietar
proceso de aprobación. Los usuarios no deben intentar acceder a información confidencial a menos que se les otorgue acceso
derechos del propietario correspondiente.
La información de la organización, o la información que se le ha confiado a la organización, debe ser
protegido de una manera acorde con su sensibilidad y criticidad. Las medidas de seguridad deben ser
empleado independientemente del medio en el que se almacena la información (en papel o electrónico), los sistemas
que lo procesan (por ejemplo, computadoras personales, dispositivos móviles, etc.), o los métodos por los cuales se mueve
(por ejemplo, correo electrónico, mensajería instantánea, conversación cara a cara, etc.). La información también debe ser
constantemente protegido sin importar cuál sea su etapa en el ciclo de vida desde el origen hasta la destrucción.
Funciones y responsabilidades de seguridad de la información
La seguridad de la información se logra mediante un esfuerzo en equipo que involucra la participación y el apoyo
de cada usuario que se ocupa de la información y los sistemas de información. Una seguridad de la información
Página 357
El departamento generalmente tiene la responsabilidad principal de establecer pautas, dirección y

autoridad sobre las actividades de seguridad de la información. Sin embargo, todos los grupos tienen un rol y
responsabilidades en la protección de la información de la organización, como se describe a continuación
secciones.
Responsabilidades del propietario de la información

Los propietarios de la información son los gerentes de departamento, la alta gerencia o sus designados dentro
la organización que tiene la responsabilidad de la adquisición, el desarrollo y el mantenimiento de
aplicaciones de producción que procesan información. Las aplicaciones de producción son programas de computadora
que proporcionan informes periódicamente en apoyo de la toma de decisiones y otras actividades de la organización.
Toda la información del sistema de aplicación de producción debe tener un propietario designado. Para cada tipo de
información, los propietarios designan la clasificación de sensibilidad relevante, designan el nivel apropiado
de criticidad, definir qué usuarios tendrán acceso, así como aprobar solicitudes de varias formas
en el que se utilizará la información.
Responsabilidades del custodio de la información

Los custodios están en posesión física o lógica de información o información de la organización
que se ha confiado a la organización. Mientras que los miembros del personal de TI son claramente custodios,
los administradores del sistema también son custodios. Siempre que la información se mantenga solo de forma personal
ordenador, el usuario es necesariamente también el custodio. Cada tipo de información del sistema de aplicación
debe tener uno o más conserjes designados. Los custodios son responsables de salvaguardar la
información, incluida la implementación de sistemas de control de acceso para evitar la divulgación inapropiada
y realizar copias de seguridad para que no se pierda información crítica. Los custodios también están obligados a
implementar, operar y mantener las medidas de seguridad definidas por los propietarios de la información.
Responsabilidades del usuario

Los usuarios son responsables de familiarizarse (y cumplir) con todas las políticas, procedimientos
normas y estándares relacionados con la seguridad de la información. Preguntas sobre el apropiado
El manejo de un tipo específico de información debe dirigirse al custodio o al
propietario de la información involucrada. A medida que los sistemas de información se distribuyen cada vez más
(por ejemplo, a través de la informática móvil, la informática de escritorio, etc.), los usuarios se colocan cada vez más en un
posición donde deben manejar asuntos de seguridad de la información que no manejaron en días
pasado. Estos nuevos sistemas distribuidos obligan a los usuarios a desempeñar roles de seguridad que no tenían
jugado anteriormente.
Responsabilidades de terceros
El acceso a la información de terceros debe controlarse formalmente. Con el uso de contratistas
y subcontratación, terceros tendrán la necesidad de acceder a la información de la organización. Allí
debe existir un proceso para otorgar el acceso requerido cumpliendo con las reglas y regulaciones.
Este proceso debe incluir un acuerdo de no divulgación firmado por un tercero que defina
responsabilidad por el uso de esa información. Debería implementarse un proceso similar cuando las personas en
la organización tiene acceso a información de terceros.
Página 358
Controles de seguridad de la información

En la cultura organizacional actual, la mayoría de los desafíos de seguridad de la información se abordan con
herramientas y tecnologías de seguridad, como cifrado, firewalls, gestión de acceso, etc.
Las herramientas y tecnologías son ciertamente una parte integral de los planes de seguridad de la información de las organi
la literatura sostiene que por sí solos no son suficientes para abordar los problemas de seguridad de la información. A
mejorar la seguridad de la información en general, las organizaciones deben implementar ISC que satisfagan sus
requerimientos de seguridad.
Según ISO / IEC 27002, “la seguridad de la información se logra mediante la implementación de un conjunto adecuado
de controles, incluidas políticas, procesos, procedimientos, estructuras organizativas y software y
funciones de hardware ". Estos controles deben diseñarse e implementarse de manera efectiva para garantizar
que se cumplan realmente los objetivos empresariales y de seguridad específicos de la organización. NIST define ISC o
controles de seguridad como “una salvaguarda o contramedida prescrita para un sistema de información o un
organización diseñada para proteger la confidencialidad, integridad y disponibilidad de su información
y para cumplir con un conjunto de requisitos de seguridad definidos ". *
Un ejemplo muy común de un ISC en las organizaciones implica la revisión y el seguimiento de
Eventos relevantes para la seguridad informática. Sistemas informáticos que manejan datos sensibles, valiosos o críticos.
La información debe registrar de forma segura todos los eventos importantes de seguridad informática. Ejemplos de com-
Los eventos relevantes para la seguridad informática incluyen intentos de adivinar contraseñas, intentos de usar privilegios q
no han sido autorizados, modificaciones al software de aplicación de producción y modificaciones
al software del sistema. Los registros de eventos relevantes para la seguridad informática deben proporcionar datos suficient
respaldar auditorías integrales de la efectividad y el cumplimiento de las medidas de seguridad. Todas
Los comandos emitidos por los operadores del sistema informático deben ser rastreables hasta individuos específicos a travé
el uso de registros completos. Se deben conservar los registros que contengan eventos relevantes para la seguridad informáti
según los procedimientos de archivo establecidos. Durante este período, dichos registros deben asegurarse de manera que
no pueden modificarse y de tal modo que sólo puedan ser leídos por personas autorizadas. Estos registros son
importante para la corrección de errores, auditoría forense, recuperación de brechas de seguridad y esfuerzos relacionados. A
Asegurar que los usuarios sean responsables de sus acciones en los sistemas informáticos, uno o más registros.
El seguimiento de las actividades relevantes para la seguridad de usuarios específicos debe mantenerse de forma segura dura
período. Registros computarizados que reflejan los privilegios de acceso de cada usuario de sistemas multiusuario y
las redes deben mantenerse de forma segura durante un período razonable.
Otros ISC comunes que ayudan a las organizaciones se incluyen como parte de la vulnerabilidad, amenaza,
procesos de gestión de confianza, identidad y de incidentes que se describen a continuación.
Gestión de vulnerabilidades
Las vulnerabilidades se refieren a “debilidades o exposiciones en los activos o procesos de TI que pueden generar un riesgo
o un riesgo de seguridad ". Se necesita un proceso de gestión de vulnerabilidades para combatir estos riesgos específicos. los
El proceso incluye la identificación, evaluación y reparación de vulnerabilidades. Requisitos previos para
responder a las vulnerabilidades incluyen procesos de gestión de activos para determinar el software instalado
en el hardware de la organización, así como en los procesos de gestión de cambios para gestionar las pruebas de parches.
Los parches deben revisarse y probarse antes de la implementación para verificar que el sistema continúa funcionando.
funcionan según lo previsto y que no se introducen nuevas vulnerabilidades. Con estos procesos en su lugar, el
El grupo de seguridad de la información puede identificar las vulnerabilidades que se aplican a la organización. Una vez iden
Si se cumplen, las vulnerabilidades deben priorizarse e implementarse en función del riesgo del problema en particular.
Página 359
Gestión de amenazas
La gestión de amenazas incluye protección antivirus, control de spam, detección de intrusos y seguridad.
gestión de eventos. El software de protección antivirus debe cargarse en todas las estaciones de trabajo y los servidores.
para escanear regularmente el sistema en busca de nuevas infecciones. Tarde o temprano, un virus llegará a un
sistema. Incluso algunos de los mayores proveedores de software han enviado productos con virus por error.
Se deben implementar políticas relacionadas con la protección contra virus para prevenir, detectar y corregir virus.
El software antivirus debe actualizarse continuamente con definiciones de virus a medida que se introducen nuevos virus.
diario. La formación de concienciación del usuario es otro control importante para que los usuarios sean conscientes del peli
al sistema del software infectado que se descarga desde cualquier fuente.
Gestión de confianza
La gestión de confianza incluye controles de acceso y cifrado. Para garantizar que la criptografía se aplique en
conformidad con disciplinas sólidas, tiene que haber una política formal sobre el uso de la criptografía que
se aplica en toda la organización. Una política formal debe estar respaldada por estándares integrales /
directrices (por ejemplo, para la selección de algoritmos, gestión de claves criptográficas, etc.) y tener en cuenta
restricciones transfronterizas de la cuenta. Muchas rutinas de cifrado requieren que el usuario proporcione una semilla
o una tecla como entrada. Los usuarios deben proteger estos parámetros de seguridad de la divulgación no autorizada, simpl
ya que protegerían las contraseñas de la divulgación no autorizada. Reglas para elegir semillas fuertes o
Asimismo, las claves deben seguir las reglas para elegir contraseñas seguras.
Las tecnologías de cifrado almacenan electrónicamente información en una forma codificada que solo puede
ser decodificados por una persona autorizada que tenga la tecnología de descifrado adecuada y
autorización para descifrar. El cifrado proporciona una serie de componentes de seguridad importantes para
proteger información electrónica como:
◾ Identificación . ¿Quién eres tú?

◾ Autenticación. ¿Puedes demostrar quién eres?
◾ Autorización. ¿Qué puedes hacer?
◾ Auditoría. ¿Qué hiciste?
◾ Integridad. ¿Es inviolable?
◾ Privacidad. ¿Quién puede verlo?
◾ No repudio. ¿Puedo probar que dijiste lo que dijiste?
Cuando la información está codificada, primero se traduce a una forma numérica y luego se cifra utilizando
un algoritmo matemático. El algoritmo requiere un número o mensaje, llamado clave, para codificar
o decodificar la información. El algoritmo no puede decodificar la información cifrada sin un
decodificar clave.
Gestión de identidad
La gestión de la identidad es el proceso que se utiliza para determinar quién tiene acceso a qué en una organización.
También es una de las áreas más difíciles de gestionar debido a la cantidad de funciones que deben trabajar.
juntos para implementar los controles adecuados. La gestión de la identidad debe ser un esfuerzo de colaboración entre
seguridad de la información, desarrollo de aplicaciones, operaciones, recursos humanos, contratos / adquisiciones,
y grupos empresariales para implementar. Hay muchas razones para implementar una gestión de identidad.
solución: cumplimiento normativo, gestión de riesgos y reducción de gastos, por mencionar algunos.
Página 360
Automatizar la gestión de identidades en una sola aplicación que gestiona el acceso a los sistemas
acelera el desarrollo de aplicaciones y reduce los costos operativos. Las organizaciones se han desarrollado
sistemas y aplicaciones a lo largo del tiempo con programas de identidad de usuario independientes. Con el numero de
aplicaciones y sistemas aumentan, los usuarios tienen dificultades para recordar el número de usuarios
ID y contraseñas. Esto hace que los usuarios creen contraseñas fáciles de adivinar, escriban contraseñas, no
cámbielos o cambie un solo dígito.
La implementación de la gestión de identidades puede generar ahorros para la mesa de ayuda con llamadas reducidas
volumen y operaciones de menos cambios de contraseña, y a usuarios con mayor productividad de
tiempo de inicio de sesión reducido y restablecimiento de contraseña. Implementar un proceso común para administrar el ac
rights proporciona un nivel coherente, seguridad y responsabilidad en todas las aplicaciones. Automatizando
La gestión de identidades puede permitir la implementación de derechos de acceso de seguridad basados en roles comerciale
mejorar el tiempo de respuesta para agregar, cambiar y eliminar el acceso. Los beneficios adicionales incluyen:
◾ Procesos manuales reducidos y potencial de error humano

◾ Mejora de los informes de gestión de los derechos de acceso de los usuarios
◾ Capacidad para hacer cumplir la segregación de funciones de acuerdo con las reglas comerciales
◾ Derechos de acceso revocados automáticamente de empleados inactivos
◾ Seguimiento de auditoría de solicitudes y aprobaciones
La integración de todos estos sistemas con un programa de gestión de identidades común puede resultar costosa y
pérdida de tiempo. The Gartner Group recomienda implementar la gestión de identidades a lo largo del tiempo
probando primero el éxito con una sola función o aplicación.
Administracion de incidentes
Incidentes de seguridad, como mal funcionamiento, pérdida de energía o servicios de comunicaciones, sobrecargas,
Los errores cometidos por los usuarios o el personal que ejecuta las instalaciones, las violaciones de acceso, etc., deben ser
gestionados y tratados de acuerdo con un proceso formal. El proceso tiene que aplicarse a todas las formas
de incidente de seguridad. Los incidentes deben ser:
◾ Identificado y registrado
◾ Reportado a un punto focal
◾ Priorizado para la acción
◾ Analizado y actuado
Cada incidente debe ser tratado por una persona equipada para comprender todas las implicaciones.
del incidente, así como las consecuencias para la organización e iniciar la acción apropiada.
Los incidentes importantes y el patrón de incidentes a lo largo del tiempo deben ser informados y revisados.
por la persona a cargo y por los representantes de los usuarios, de modo que se pueda iniciar la acción apropiada y
debidamente documentado. Los incidentes deben informarse a la dirección.
Selección y prueba de controles de seguridad de la información
Debido a una variedad de limitaciones específicas de la organización (por ejemplo, costos, disponibilidad de recursos, etc.),
las organizaciones no pueden darse el lujo de seleccionar todos los ISC requeridos. La selección adecuada de ISC es
crucial para las organizaciones en el mantenimiento de una sólida seguridad de la información, así como en la protección
Página 361
activos de información financiera. La literatura señala varios problemas, lagunas y / o debilidades que
prevenir una selección efectiva de ISC en las organizaciones. Estas debilidades también impactan en el
protección de la confidencialidad, integridad y disponibilidad de la información. En otras palabras, la falta
seguridad de la información adecuada sobre información financiera valiosa, sensible o crítica puede
permitir: (1) fraude, manipulación y / o uso indebido de datos; (2) deficiencias relacionadas con la seguridad y
recomendaciones; (3) operaciones falsas para inflar las ganancias u ocultar pérdidas; (4) asientos contables falsos en el diario
brechas de seguridad informática; y (6) transacciones falsas para evadir a los reguladores, entre muchas otras.
ISO / IEC 27002 establece que después de la identificación de los riesgos de seguridad, los controles apropiados
deben seleccionarse (e implementarse) para garantizar que esos riesgos se reduzcan a niveles aceptables.
Los ISC de uso común se han incluido en el Apéndice 3 del Capítulo 3. Se ofrecen ISC adicionales
según la norma ISO / IEC 27002. El punto principal aquí es que la selección de ISC depende
sobre decisiones organizativas y necesidades específicas. Dicha selección también se basa en los criterios de
aceptación del riesgo, opciones de tratamiento del riesgo y el enfoque general de gestión del riesgo aplicado al
organización. La selección de ISC también debe estar sujeta a todos los requisitos nacionales e internacionales pertinentes.
legislación y reglamentos. Los ISC incluidos en el Apéndice 3 del Capítulo 3 y en ISO / IEC 27002 son
aplicable a la mayoría de las organizaciones y considerado como principios rectores tanto para la seguridad de la informació
auditores de gestión de la sociedad y de TI.
Probar ISC es esencial para mantener sistemas de información adecuados y seguros. Sin embargo,
La mayoría de las organizaciones no realizan pruebas efectivas (y exhaustivas) del sistema de información.
tems, o carecen de los mecanismos y controles para realizar las pruebas requeridas. Nada puede sustituir
para evaluar ISC. Algunas de las razones de la falta de pruebas incluyen:
◾ Liderazgo que no proporciona expectativas claras para evaluar controles y / o programas de pruebas
◾ Supervisión inadecuada del programa de gestión de riesgos
◾ Falta de administradores de pruebas y evaluadores / evaluadores de seguridad capacitados
◾ Presión de los líderes para condensar el ciclo de pruebas debido a que el programa tiene una prioridad más alta
que la seguridad de un sistema
La única forma de saber si un ISC funciona o no, si pasa o no, es probarlo. Prueba de ISC
no se puede lograr a través de una herramienta de escaneo de vulnerabilidades, que solo verifica una pequeña cantidad de
controles de seguridad. Un escaneo de vulnerabilidades a menudo prueba una fracción, aproximadamente el cinco por ciento
controles de seguridad.
Al probar ISC, el NIST RMF recomienda el desarrollo y ejecución de un plan de prueba.
El plan de prueba debe incluir todos los controles aplicables al sistema de información específico. Probadores
debe ejecutar el plan de prueba con el propietario del sistema de información y registrar los resultados, que por
el marco NIST RMF, incluyen:
◾ Una lista de controles de seguridad aplicables

◾ Un plan de prueba que abarque todos los controles de seguridad aplicables
◾ Un informe de prueba (pasa / no pasa)
◾ Mitigaciones para los controles fallidos
Los resultados de las pruebas proporcionan al ejecutivo de riesgos la información necesaria para tomar una decisión de riesg
El ejecutivo de riesgos suele ser el director de información (CIO), el CIO adjunto, el director de información
oficial de seguridad (CISO) o director de gestión de riesgos. Desde el punto de vista de la auditoría de TI, los resultados de l
apoyar el trabajo de auditoría y la conclusión, y formar la base para la comunicación de salida formal con
la gestión de la organización.
Página 362
Participación en una auditoría de seguridad de la información

Según ISACA, una auditoría de la seguridad de la información de una organización proporciona gestión
con una evaluación de la eficacia de la función de seguridad de la información sobre los sistemas de TI
(por ejemplo, computadoras, servidores, mainframes, enrutadores de red, conmutadores, etc.). La seguridad de la informació
La auditoría también ayuda a determinar si los procesos, controles y / o procedimientos de seguridad esenciales son
faltantes o realmente en su lugar (lo que significa que están adecuadamente diseñados, implementados y operando
comió con eficacia). Estas evaluaciones se realizan normalmente de forma manual y / o mediante programas automatizados.
ceduras. Las evaluaciones manuales pueden incluir entrevistas al personal de la organización (por ejemplo, personal de segu
etc.), realizar análisis de vulnerabilidades de seguridad, revisar los controles de acceso al sistema y a las aplicaciones, y
analizar el acceso físico a los sistemas, entre otros. Las evaluaciones automatizadas generalmente involucran
el uso de técnicas de auditoría asistidas por computadora (CAAT) o software para ayudar a los auditores a revisar y
probar controles de aplicaciones, así como seleccionar y analizar datos computarizados para pruebas de auditoría sustantivas
La seguridad de la información de auditoría cubre temas como: función de administración de seguridad, seguridad
Políticas y procedimientos, herramientas y técnicas de software de seguridad, identificadores únicos de usuario y
Contraseñas, seguridad física, administrador de seguridad y acceso privilegiado, seguridad de la información
Registros y otros. Procedimientos o controles de seguridad de la información insuficientes o inadecuados, sin embargo,
puede resultar en riesgos para organizaciones como las siguientes:
◾ Si las herramientas y técnicas de seguridad lógica no se implementan, configuran o administran

apropiadamente, las actividades de control dentro de los flujos significativos de transacciones pueden ser ineficaces,
Es posible que no se aplique la segregación de funciones deseada, y recursos de información importantes
puede modificarse de manera inapropiada, divulgarse sin autorización, dejar de estar disponible cuando
necesario y / o eliminado sin autorización. Además, tales violaciones de seguridad pueden desaparecer
sin ser detectado.
◾ Si una organización confía en las características de seguridad de sus sistemas de aplicaciones para restringir el acceso a
funciones de aplicación sensibles, debilidades en la seguridad de la red o del sistema operativo (por ejemplo,
autenticación de usuario y acceso general al sistema, etc.) pueden hacer que dicha aplicación de seguridad
características ineficaces.
Los objetivos de auditoría comunes de una auditoría de seguridad de la información incluyen garantizar que:
◾ La configuración de seguridad de aplicaciones, bases de datos, redes y sistemas operativos es adecuada

debidamente administrado para proteger contra cambios no autorizados en programas y datos que pueden
resultar en un procesamiento o registro incompleto, inexacto o inválido de información financiera.
◾ Se implementa una seguridad efectiva para proteger contra accesos y modificaciones no autorizados
de sistemas e información, que puede resultar en el procesamiento o registro de datos incompletos,
información financiera inexacta o no válida.
Sin la implementación de controles apropiados, daños innecesarios o interrupciones en el

la información de la organización podría ocurrir. Tal daño podría resultar en la falla de la organización
procesos críticos. Se deben implementar actividades de control para reducir los riesgos y abordar los objetivos.
como
ridad yelprotección
anterior. Por ejemplo,
contra la implementación
cambios de programas
no autorizados en actividadesyde control
datos adecuadas
dentro garantizaría
de aplicaciones, la seguridad
datos
bases, redes y sistemas operativos, que pueden resultar en datos incompletos, inexactos o inválidos
procesamiento o registro de información financiera (primer objetivo anterior). Seguridad de información
Los controles y procedimientos revisados por los auditores de TI normalmente probarían y examinarían que:
Página 363
◾ La función de administración de seguridad debe estar separada de la función de TI.

◾ Las políticas y procedimientos formales definen los objetivos de seguridad de la información de la organización y
las responsabilidades de los empleados con respecto a la protección y divulgación de información
recursos nacionales. La gerencia monitorea el cumplimiento de las políticas y procedimientos de seguridad,
y el acuerdo con estos se evidencia mediante la firma de los empleados.
◾ Existen herramientas y técnicas de software relacionadas con la seguridad para restringir y segregar el acceso
a funciones de TI sensibles (por ejemplo, programación, funciones administrativas, implementación de
cambios en los entornos de producción, etc.) dentro de los sistemas. Los cambios relacionados con el acceso son
evaluado por la dirección para la adecuada separación de funciones.
◾ Se revisa la implementación y configuración de herramientas y técnicas de software de seguridad.
y aprobado por la gerencia.
◾ Se han asignado identificadores de usuario únicos a los usuarios según lo requerido en la seguridad de la información.
políticas y procedimientos, para distinguirlos y hacer cumplir la responsabilidad.
◾ Los usuarios locales y remotos deben autenticarse en aplicaciones, bases de datos, redes,
y sistemas operativos mediante contraseñas para mejorar la seguridad informática.
◾ Las contraseñas promueven niveles aceptables de seguridad (de acuerdo con las políticas y / o las mejores
prácticas) al hacer cumplir la confidencialidad y un formato de contraseña seguro.
◾ Contraseñas proporcionadas por el proveedor integradas en las aplicaciones, bases de datos, redes y
los sistemas operativos se modifican, eliminan o desactivan para evitar vulnerabilidades de seguridad
de ser explotado en los sistemas.
◾ El acceso a la cuenta de administrador, privilegiado o superusuario dentro de los sistemas está limitado a
personal apropiado. Cambios en estas cuentas (p. Ej., Parámetros de seguridad del sistema, seguridad
roles, configuración de seguridad de los sistemas, etc.) son registrados y revisados por la gerencia.
◾ Los registros de seguridad de la información se configuran y activan en aplicaciones, bases de datos, redes,
y sistemas operativos para registrar e informar eventos de seguridad coherentes con la información
políticas y procedimientos de seguridad.
◾ Informes generados a partir de registros de seguridad de la información (por ejemplo, informes de violaciones de segur
intentos de acceder a información, etc.) se revisan con frecuencia y se toman las medidas necesarias.
Para garantizar que se implemente una seguridad efectiva para proteger contra accesos y modificaciones no autorizados
de sistemas e información, lo que puede resultar en el procesamiento o registro de datos incompletos,
Las actividades de control de información financiera curada o no válida probarían que:
◾ Se han establecido programas de capacitación para todo el personal dentro de las siguientes áreas:
- Políticas de seguridad organizacional
- Divulgación de datos sensibles
- Privilegios de acceso a los recursos de TI
- Notificación de incidentes de seguridad
- Convenciones de nomenclatura para contraseñas de usuarios
◾ Los propietarios del sistema autorizan las cuentas de usuario y la naturaleza y extensión de sus privilegios de acceso.
◾ Los propietarios del sistema y la aplicación revisan periódicamente los privilegios de acceso a la cuenta de usuario par
determinar si son razonables y / o siguen siendo apropiados.
◾ Usuarios que han
o cancelados soncambiado de inmediatamente
informados roles o tareas dentro de la organización,
al departamento o que para
de seguridad han sido transferidos,
el acceso a la cuenta de usuario
revisión para reflejar el estado nuevo y / o revisado.
◾ La transmisión de información confidencial está encriptada de acuerdo con las políticas de seguridad y
procedimientos para proteger su confidencialidad.
Página 364
Herramientas de auditoría y mejores prácticas

Como se indicó anteriormente, el Instituto SANS proporciona varias plantillas de políticas de seguridad de la información, *
son muy prácticos y sirven como un gran punto de partida para un rápido desarrollo e implementación
de las políticas de seguridad de la información. Plantillas de políticas de seguridad de la información desarrolladas por el Ins
cubrir áreas comunes y relevantes en el campo de la seguridad de la información, tales como: Información general
Seguridad, Seguridad de la Red, Seguridad del Servidor y Seguridad de las Aplicaciones, entre otros.
El Apéndice 3 (discutido en el Capítulo 3) también proporciona un programa de auditoría de TI de muestra para el
Área de TI de control general de seguridad de la información, que incluye una lista completa de control de auditoría
objetivos y actividades que deben seguirse y realizarse al realizar dicho examen.
Dependiendo del tamaño y complejidad de la organización, estos objetivos y actividades de control
puede ser necesario revisar o ampliar para obtener una cobertura de auditoría adecuada de la seguridad de la información
función.
Otra buena fuente de herramientas y mejores prácticas es ISACA. ISACA actualmente proporciona Auditoría /
Programas de aseguramiento † basados en COBIT 5 para lo siguiente, entre otros:
◾ Programa de aseguramiento / auditoría de informática móvil

◾ Programa de auditoría de privacidad de datos
◾ Programa de aseguramiento / auditoría de TI subcontratado
◾ Ciberseguridad: basado en el marco de ciberseguridad del NIST
◾ Programa de garantía / auditoría de seguridad Traiga su propio dispositivo (BYOD)
◾ Programa de aseguramiento / auditoría de gestión de cambios
◾ Programa de aseguramiento / auditoría de gestión de computación en la nube
◾ Programa de aseguramiento / auditoría de gestión de riesgos de TI
◾ Programa de auditoría / garantía del programa de cumplimiento de PCI DSS e ICQ
◾ Programa de auditoría / aseguramiento del ciclo económico de ingresos de SAP ERP e ICQ
◾ Programa de auditoría / aseguramiento del ciclo económico de gastos de SAP ERP e ICQ
◾ Programa de auditoría / aseguramiento del ciclo comercial de inventario de SAP ERP e ICQ
◾ Programa de auditoría / aseguramiento de SAP ERP Financial Accounting (FI) e ICQ
◾ Programa de auditoría / aseguramiento de contabilidad gerencial (CO) SAP ERP e ICQ
◾ Programa de aseguramiento / auditoría del ciclo de gestión de capital humano de SAP ERP e ICQ
◾ Programa de auditoría / garantía de seguridad y administración SAP ERP BASIS e ICQ
◾ Entorno de control SAP ERP ICQ
Referencias adicionales de información de auditoría relevante o buenas prácticas al embarcarse en información

Las auditorías de seguridad de la industria, particularmente relacionadas con las tecnologías recientes que impactan el entorn
que se muestra en el Cuadro 12.3.
Conclusión
La información representa un activo fundamental en la mayoría de las organizaciones en la actualidad. Sin confiable y adecu
información
La seguridadprotegida, las organizaciones
de la información no durarían
ayuda a garantizar que mucho y, en los
se cumplan cambio, podrían
objetivos cerrar rápidamente.
comerciales estratégicos de la organización.
* https://www.sans.org/security-resources/policies/#template.
† http://www.isaca.org/knowledge-center/research/pages/audit-assurance-programs.aspx?cid=1003563&appeal=pr.
Página 365
Figura 12.3 Referencias adicionales de información de auditoría relevante o buenas prácticas

Al emprender auditorías de seguridad de la información relacionadas con tecnologías recientes
Impactando el entorno de TI
Tecnología / Fuente Descripción
Alianza de seguridad en la nube Grupo de trabajo de CloudAudit
Instituto Nacional de Estándares Directrices sobre seguridad y privacidad en la nube pública

y Tecnología, Especial Informática
Publicación 800-144
Deloitte Computación en la nube: la guía para auditores que no son de TI para

Auditando la nube
PWC Una guía para auditorías en la nube
ISACA Auditoría de la computación en la nube: una guía de seguridad y privacidad
El Instituto SANS Métodos de auditoría del marco de seguridad en la nube
Big Data
IIA Guía de auditoría de tecnología global (GTAG): comprensión

y auditoría de Big Data
AICPA Análisis de auditoría y auditoría continua: mirando hacia

el futuro
ISACA ¿Qué es Big Data y qué tiene que ver con la auditoría de TI?
Dispositivos móviles
Instituto Nacional de Estándares Directrices para administrar y proteger dispositivos móviles en

y Tecnología, Especial la empresa
Publicación 800-124 Revisión 1
Internet de las Cosas
Deloitte Auditoría de Internet de las cosas
ISACA Internet de las cosas: consideraciones de riesgo y valor
OWASP Guías de prueba de IoT
EY Ciberseguridad e Internet de las cosas
Blockchain
Deloitte Blockchain y ciberseguridad
EY Blockchain y el futuro de la auditoría
PWC Auditoría de blockchain: una nueva frontera

ISACA Cómo navegar Blockchain: la tecnología que podría
Cambia todo
ISO / TC 307 Tecnologías blockchain y de contabilidad distribuida
Página 366
objetivos fundamentales para la información y los sistemas de información que son esenciales para mantener
ventaja competitiva, flujo de caja, rentabilidad, cumplimiento legal y una imagen respetada de la organización son
confidencialidad, integridad y disponibilidad. El cumplimiento de estos objetivos también es fundamental
al protegerse contra el creciente número de amenazas y riesgos de seguridad de la información.
La tecnología está en constante evolución y encuentra formas de dar forma al entorno de TI actual en
la organización. Tecnologías recientes (por ejemplo, ERP, Cloud Computing, MDM, IoT, Big Data,
Blockchain, Wearables, etc.) ya han comenzado a revolucionar las organizaciones, cómo los negocios
se hace, y la dinámica del lugar de trabajo. Implementación efectiva de la seguridad de la información
dentro de estas tecnologías es primordial para mitigar los riesgos y proteger la información.
Los estándares y directrices de seguridad de la información proporcionan un marco para implementar
procesos y controles de seguridad exhaustivos. Tres informaciones sobre mejores prácticas ampliamente reconocidas
Los estándares de seguridad son COBIT, ISO / IEC 27002 y NIST. Proporcionan a las organizaciones
los medios para abordar diferentes ángulos dentro del campo de la seguridad de la información.
Una política de seguridad de la información está destinada a guiar a las organizaciones en la toma de decisiones sobre
seguridad de información. Una política de seguridad de la información proporciona declaraciones de información de alto niv
metas, objetivos, creencias, ética, controles y responsabilidades de seguridad. Estándares y pautas
que definen la implementación específica de las políticas se documentan por separado. La organización,
gestión y personal y los profesionales de auditoría, control y seguridad de TI deben trabajar juntos para
establecer, mantener y monitorear la política de seguridad de la información de la organización.
Para ser eficaz, la seguridad de la información debe lograrse mediante un esfuerzo de equipo que involucre al
participación y apoyo de todos los usuarios que se ocupan de la información y los sistemas de información. Un
El departamento de seguridad de la información generalmente tiene la responsabilidad principal de establecer guías
líneas, dirección y autoridad sobre las actividades de seguridad de la información. Sin embargo, todos los grupos deben
tienen un rol y responsabilidades específicas en la protección de la información de la organización.
ISC ayuda a la organización a lograr niveles adecuados de seguridad. Incluyen implementados
políticas, procesos, procedimientos, estructuras organizativas y funciones de software y hardware,
entre otros, que refuerzan la seguridad en la organización. Es necesario diseñar e implementar ISC
eficazmente para garantizar que se logren los objetivos comerciales y de seguridad de la organización. Ellos deben
también ser monitoreados, revisados y mejorados, cuando sea necesario. Las organizaciones deben seleccionar y probar
ISC para satisfacer requisitos de seguridad específicos y mejorar la seguridad general de la información.
1. Explique cada uno de los tres objetivos comerciales estratégicos de la organización logrados mediante
implementación de seguridad de la información. ¿Cuáles son los riesgos asociados que evitarían
lograrlos?
2. Elija dos de las tecnologías recientes discutidas en este capítulo que ya han comenzado a
revolucionar las organizaciones, la forma de hacer negocios y la dinámica del lugar de trabajo.
Describa la tecnología y proporcione ejemplos de tres riesgos que probablemente cada tecnología
agregar a la organización.
3. Describa brevemente seis técnicas de uso común que se utilizan para cometer delitos cibernéticos según
Este capítulo.
4. Defina COBIT. Describa los principios de COBIT 5 que ayudan a las organizaciones a crear
valor de TI manteniendo un equilibrio entre obtener beneficios y optimizar los niveles de riesgo
y uso de recursos.
5. ¿Cuál es el propósito de una política de seguridad de la información?
Página 367
6. Enumere y describa los roles típicos dentro de la seguridad de la información y sus responsabilidades en
proteger la información de la organización.
7. Proporcione dos o tres ejemplos de controles de seguridad de la información dentro de los siguientes
procesos de gestión:
a. Vulnerabilidad
segundo. Amenaza
C. Confiar
re. Identidad
mi. Incidente
8. Los resultados de las pruebas de seguridad de la información deben registrarse y, de acuerdo con el NIST, esos
los resultados deben incluir?
9. La empresa para la que trabaja está en proceso de determinar si debe disponer de información
auditoría de seguridad (ISA) realizada. Aunque la Compañía no está obligada (todavía) a tener un
ISA para propósitos de cumplimiento de leyes, reglas y / o regulaciones, ellos son muy conscientes de la
beneficios que dicha auditoría puede proporcionar. Sin embargo, también saben lo caras que son estas auditorías espe
son. ¿Estaría dispuesto a aconsejar a su empresa que se someta a este tipo de auditoría, sí o
¿No? Explique su posición.
10. Enumere 10 fuentes de herramientas de auditoría, mejores prácticas y / o información de auditoría relevante cuando
realizar auditorías de seguridad de la información que se discutieron en este capítulo.
Ejercicios
1. El Cuadro 12.1 enumera las técnicas comunes utilizadas para cometer delitos cibernéticos. Para cada uno de estos
técnicas, investigue en Internet y proporcione los nombres de una o dos entidades que han
se ha visto afectado por dicha técnica en los últimos 5-7 años. Describe brevemente cómo la técnica
fue utilizado en el ataque.
2. Enumere información, capturas de pantalla, informes, etc. que el auditor de TI probablemente solicitaría a un
cliente para realizar una auditoría de seguridad de la información. Por qué es importante esta información
para el auditor de TI?
3. Un cliente potencial le pide que proporcione un borrador del programa de auditoría de TI (objetivos y
procedimientos de control) que utilizaría y seguiría para auditar la seguridad de la información en su
organización. Proporcione su respuesta en formato de memorando, documentando (a) los objetivos de la auditoría
El programa de auditoría se centrará en, y (b) las actividades de control que deberían evaluarse en
para cumplir con los objetivos de auditoría que se acaban de enumerar.
CASO: PROGRAMA DE AUDITORÍA DE SEGURIDAD DE LA INFORMACIÓN
INSTRUCCIONES: Investigue en Internet e identifique dos grandes ciberataques recientes.

en los últimos 3 años.
TAREA:
que sufrióPara cada ataque,
el ataque, así como(1)proporcionar
describa brevemente
una breveladescripción
naturaleza yresumida
las operaciones de la
del ataque enorganización
sí.
Luego, (2) elabore una lista de controles y procedimientos de auditoría de seguridad de la información que,
que estuvieran en su lugar, habrían ayudado a mitigar o reducir el impacto del ataque. Por último, (3)
Explique cómo cada control de auditoría de seguridad de la información que enumeró habría ayudado a mitigar
Página 368
o reducir el ataque. Debe buscar más allá del capítulo (es decir, literatura de TI y /
o cualquier otra fuente externa válida) para respaldar su respuesta. Incluya ejemplos, según corresponda
comió, para evidenciar su caso. Envíe un archivo de Word con una portada, respuestas a la tarea.
arriba, y una sección de referencia al final. El archivo enviado debe tener entre 8 y 10
páginas (interlineado doble), incluida la portada y las referencias. Esté listo para presentar
tu trabajo a la clase.
Otras lecturas
1. AICPA. Análisis de auditoría y auditoría continua: mirando hacia el futuro. www.aicpa.org/
2. PWC. Auditoría de blockchain: una nueva frontera. www.pwc.com/us/en/financial-services/research-
institute / blog / blockchain-audit-a-michael-smith.html (consultado en septiembre de 2017).
3. Bacon, M. St. Jude Medical finalmente parchea los dispositivos médicos vulnerables de IoT, TechTarget , https: // search-
security.techtarget.com/news/450410935/St-Jude-Medical-finally-patches-vulnerable-medical-IoT-
dispositivos (consultado el 13 de enero de 2017).
4. Inteligencia de BI. Así es como explotará Internet de las cosas para 2020, Business Insider , www.busines-
sinsider.com/iot-ecosystem-internet-of-things-forecasts-and-business-opportunities-2016-2 (consultado
31 de agosto de 2016).
5. Deloitte. Blockchain y ciberseguridad. www2.deloitte.com/content/dam/Deloitte/ie/Documents/
Technology / IE_C_BlockchainandCyberPOV_0417.pdf (consultado en septiembre de 2017).
6. ISO / TC 307. Blockchain y tecnologías de contabilidad distribuida. www.iso.org/committee/6266604.
html (consultado en septiembre de 2017).
7. EY. Blockchain y el futuro de la auditoría. www.ey.com/gl/en/services/assurance/ey-reporting-
blockchain-and-the-future-of-audit (consultado en septiembre de 2017).
8. Computación en la nube en 2016- Problemas y oportunidades de la empresa privada. Deloitte. www2.deloitte.com/
us / en / pages / deloitte-growth-enterprise-services / articles / private-company-cloud-computing.html
9. Cloud Security Alliance. https://cloudsecurityalliance.org/about/ (consultado en agosto de 2017).
10. Grupo de trabajo CloudAudit de Cloud Security Alliance. https://cloudsecurityalliance.org/group/
cloudaudit / # _ Overview (consultado en junio de 2017).
11. Tácticas y técnicas de ciberdelincuencia para el primer trimestre de 2017. Malware Labs. www.malwarebytes.com/pdf/labs/
Tácticas-y-técnicas-del-ciberdelito-Q1-2017.pdf
12. Da Veiga, A. y Eloff, JHP (2007). Un marco de gobierno de seguridad de la información. Informar. Sys.
Manag. , 24 (4), 361–372.
13. Deloitte LLP. (2014). Documentos de trabajo de auditoría de TI . Documento interno inédito.
14. Auditoría de Deloitte al Internet de las cosas. www2.deloitte.com/gz/en/pages/risk/articles/auditing-
theinternet-of-things.html (consultado en julio de 2017).
15. Computación en la nube de Deloitte, la guía del auditor que no es de TI para auditar la nube. www.iia.org.uk/
media / 1283828 / cloud-computing-20150617.pdf (consultado en junio de 2017).
16. Disterer, G. (2013). ISO / IEC 27000, 27001 y 27002 para la gestión de la seguridad de la información.
J. Informar. Sec., 4 (2), 92-100.
17. Dubsky, L. (2016). Evaluación de los controles de seguridad: piedra angular del marco de gestión de riesgos.
ISACA J. , 6, 2016.
18. EY big data y analítica en el proceso de auditoría. (2015). Septiembre de EY Center for Board Matters
2015. www.ey.com/Publication/vwLUAssets/ey-big-data-and-analytics-in-the-audit-process/$FILE/
ey-big-data-and-analytics-in-the-audit-process.pdf
19. Ciberseguridad e Internet de las cosas de EY. www.ey.com/Publication/vwLUAssets/
EY-ciberseguridad-e-internet-de-las-cosas / $ FILE / EY-ciberseguridad-e-internet-de-las-cosas.pdf
(consultado en agosto de 2017).
Página 369
20. ForeScout, resultados de la encuesta de seguridad de IoT. www.forescout.com/iot-security-survey-results/ (consultado en junio

2017).
21. Glosario de TI de Gartner. (Dakota del Norte). www.gartner.com/it-glossary/big-data/ (consultado en octubre de 2017).
22. El ciclo Hype 2015 de Gartner para tecnologías emergentes identifica las innovaciones informáticas que organizan
nizaciones deben monitorear. (2015). www.gartner.com/newsroom/id/3114217
23. Gartner dice que Internet de las cosas transformará el centro de datos. (2014). http://www.gartner.com/
sala de prensa / id / 2684616
24. Gikas, C. (2010). Una comparación general de los estándares FISMA, HIPAA, ISO 27000 y PCI-DSS.
Informar. Asegurar. J. , 19 (3), 132.
25. Golson, J. Los piratas informáticos de automóviles demuestran un ataque inalámbrico en Tesla Model S, The Verge , www.thever
com / 2016/9/19/12985120 / tesla-model-s-hack-vulnerabilidad-keen-labs (consultado el 19 de septiembre de 2016).
26. Gressin, S. (2017). La filtración de datos de Equifax: qué hacer. Comisión Federal de Comercio — Consumidor
Información. www.consumer.ftc.gov/blog/2017/09/equifax-data-breach-what-do
27. Herath, T. y Rao, HR (2009). Fomentar comportamientos de seguridad de la información en las organizaciones: función
de sanciones, presiones y efectividad percibida. Decis. Soporte Syst. , 47 (2), 154-165.
28. ISACA. Cómo navegar por blockchain: la tecnología que podría cambiarlo todo. http: //
www.isaca.org/About-ISACA/Press-room/News-Releases/2017/Pages/ISACA-Guidance-How-to-
Navigate-Blockchain.aspx (consultado en junio de 2017).
29. IDC. Se prevé que el gasto mundial en servicios de nube pública alcance los 266.000 millones de dólares en 2021, según
IDC, EE. UU., Www.idc.com/getdoc.jsp?containerId=prUS42889917 (consultado el 18 de julio de 2017).
30. Guía de auditoría de tecnología global (GTAG) del IIA: Comprensión y auditoría de macrodatos. https: //
global.theiia.org/standards-guidance/recommended-guidance/practice-guides/Pages/GTAG-
Understanding-and-Auditing-Big-Data.aspx (consultado en agosto de 2017).
31. ISACA, COBIT 5: A Business Framework for the Governance and Management of Enterprise IT (ISACA,
2012), 94.
32. ISACA, Insights de innovación: Principales tendencias digitales que afectan la estrategia, 2015. http://www.isaca.org/
Centro-de-conocimiento / Investigación / Páginas / isaca-innovation-insights.aspx
33. Conocimientos de innovación de ISACA. ISACA. www.isaca.org/knowledge-center/research/pages/cloud.aspx
34. Internet de las cosas de ISACA: consideraciones de riesgo y valor. www.isaca.org/knowledge-center/research/
researchdeliverables / pages / internet-of-things-risk-and-value-consider.aspx (consultado en agosto de 2017).
35. ISACA's ¿Qué es Big Data y qué tiene que ver con la auditoría de TI? www.isaca.org/Journal/
archives / 2013 / Volume-3 / Pages / What-Is-Big-Data-and-What-does-it-have-to-do-with-IT-Audit.
aspx (consultado en agosto de 2017).
36. ISO / IEC 27001- Gestión de la seguridad de la información. www.iso.org/iso/home/standards/management-
Standards / iso27001.htm (consultado en enero de 2017).
37. Mathews, L. (2017). La violación de datos de Equifax afecta a 143 millones de estadounidenses. Forbes. https: //www.forbes.
com / sites / leemathews / 2017/09/07 / equifax-data-breach-impact-143-millones-estadounidenses / # 3ab97325356f
38. McAfee Labs. (2017). Informe de predicciones de amenazas publicado en noviembre de 2016. www.mcafee.com/au/
resources / reports / rp-amenazas-predictions-2017.pdf (consultado en octubre de 2017).
39. Informe de amenazas de McAfee Labs, diciembre de 2016. www.mcafee.com/ca/resources/reports/rp-quarterly-
amenazas-dec-2016.pdf (consultado en octubre de 2017).
40. Base de datos nacional de vulnerabilidad. Instituto Nacional de Estándares y Tecnología. https: //nvd.nist.
gov / vuln / search (consultado en agosto de 2017).
41. Pautas de NIST SP 800-144 sobre seguridad y privacidad en la computación en nube pública. https: // nvlpubs.
nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf (consultado en julio de 2017).
42. Pautas de NIST SP 800-124 para administrar y proteger dispositivos móviles en la empresa. https: //
csrc.nist.gov/csrc/media/publications/sp/800-124/rev-1/final/documents/draft_sp800-124-rev1.pdf
(consultado en julio de 2017).
información financiera. En t. J. Acc. Informar. Sys. , 18 (1), 26–45.
44. Otero, AR (2015). Impacto de la participación de los auditores de TI en las auditorías financieras. En t. J. Res. Bus .Technol. ,
6 (3), 841–849.
Página 370
evaluación de control para organizaciones, IEEE Conference on Open Systems, 21-24 de octubre de 2012, Kuala
Lumpur, Malasia.
controles que utilizan funciones booleanas. En t. J. Network Secur .Appl. , 2 (4), 1–11.
47. Guías de prueba de IoT de OWASP. www.owasp.org/index.php/IoT_Testing_Guides (consultado en agosto
2017).
48. Estándares de seguridad de datos de la industria de tarjetas de pago (PCI DSS) Estándares de seguridad para datos de cuentas
proteccion. www.pcisecuritystandards.org/ (consultado en julio de 2017).
49. Seguridad PCI. (2016). Consejo de Normas de Seguridad de PCI. www.pcisecuritystandards.org/pci_security/
50. PWC's A guide to cloud audit. www.pwc.com/us/en/risk-assurance-services/publications/assets/
internal-cloud-audit-risk-guide.pdf (consultado en junio de 2017).
51. Ross, R. (2007). Gestión de riesgos de seguridad empresarial con estándares NIST. IEEE Comp Soc. , 40 (8),
88–91. doi: 10.1109 / MC.2007.284.
52. Senft, S., Gallegos, F. y Davis, A. (2012). Control y Auditoría de Tecnologías de la Información . Boca Ratón:
CRC Press / Taylor & Francis.
53. Singh, AN, Picot, A., Kranz, J., Gupta, MP y Ojha, A. (2013). Gestión de seguridad de la información
(ISM) prácticas: lecciones de casos seleccionados de la India y Alemania. Global. J. Flexible Sys. Manag. ,
14 (4), 225–239.
54. Srinivasan, M. (2012). Creación de un modelo empresarial seguro para entornos de computación en la nube. Acad. Informar.
Manag. Sci. J., 15 (1), 127-133.
55. Comisión Federal de Big Data de la TechAmerica Foundation (2012). Desmitificar los macrodatos: una práctica
guía cal para transformar los negocios del gobierno. www.techamerica.org/Docs/fileManager.
cfm? f = techamerica-bigdatareport-final.pdf
56. Las mejores soluciones de gestión de dispositivos móviles (MDM) de 2016. PC Magazine . www.pcmag.com/
article / 342695 / el-mejor-software-mdm-de-gestión-de-dispositivos-móviles-de-2016
57. Métodos de auditoría del marco de seguridad en la nube del Instituto SANS. https://www.sans.org/reading-room/
whitepapers / cloud / cloud-security-framework-audit-methods-36922 (consultado en junio de 2017).
58. Los 10 principales proveedores de software ERP y previsión del mercado 2015-2020. (2016). Las aplicaciones dirigen el mundo.
appsruntheworld.com/top-10-erp-software-vendors-and-market-forecast-2015-2020/
59. Oficina de contabilidad general de Estados Unidos. CIBERCRIMEN: las entidades públicas y privadas enfrentan desafíos
en Addressing Cyber Threats , GAO-07–705, 22 de junio de 2007.
60. Oficina de contabilidad general de los Estados Unidos. Seguridad de la información: TVA debe abordar las debilidades
Control Systems and Networks , GAO-08–526, 21 de mayo de 2008.
61. Departamento de Justicia de los Estados Unidos, Oficina Federal de Investigaciones. 2016. Informe sobre delitos en Internet. http
pdf.ic3.gov/2016_IC3Report.pdf
62. Departamento de Justicia de Estados Unidos, Oficina Federal de Investigaciones. 2015. Informe sobre delitos en Internet. https: /
63. Departamento de Justicia de Estados Unidos, Oficina Federal de Investigaciones. 2014. Informe sobre delitos en Internet. https: /
64. Suplemento estadounidense de la Encuesta mundial sobre delitos económicos de 2014, PricewaterhouseCoopers LLP, http: //
www.pwc.com/gx/en/economic-crime-survey/
65. ¿Qué es blockchain? Revista de contabilidad . (Julio de 2017). www.journalofaccountancy.com/issues/2017/
jul / what-is-blockchain.html
66. ¿Qué es la computación en la nube? Revista PC . (2016). www.pcmag.com/article2/0,2817,2372163,00.asp
67. Panorama general de los delitos de cuello blanco. Principales amenazas y programas del FBI. Qué investigamos. www.fbi.gov/
research / white-collar-crime (consultado en octubre de 2017).
68. Zorz, Z. Investigadores piratean televisores inteligentes vizio para acceder a la red doméstica, Help Net Security , www.
helpnetsecurity.com/2015/11/12/researchers-hack-vizio-smart-tvs-to-access-home-network/
(consultado el 12 de noviembre de 2015).
Página 371
Capítulo 13
Adquisición de sistemas,
Gestión De Servicios,
y subcontratación
1. Analice la importancia de establecer una estrategia de adquisición de sistemas.
2. Describa el proceso de adquisición del sistema.
3. Explicar el proceso de gestión de servicios y sus áreas.
4. Describa la subcontratación, incluidos los servicios, los beneficios y los riesgos. Discuta el proceso de
subcontratación de sistemas informáticos.
5. Describa la participación en la auditoría al auditar tanto las adquisiciones de software como el servicio.
organizaciones.
El motivo de una organización para adquirir o subcontratar sistemas es lograr de manera eficaz y eficiente
soportar uno o más procesos de negocio. Una vez definidos los objetivos comerciales para el
solución (es) que se buscan, el proceso de adquisición o subcontratación de sistemas y / o servicios puede
empezar. Tanto la adquisición como la subcontratación deben gestionarse y supervisarse adecuadamente para garantizar
que los proveedores cumplan con sus compromisos y brinden servicios consistentes con la gerencia
metas y objetivos. Los auditores y la gerencia de TI deben ser conscientes de la importancia de estos
áreas y los procesos de control críticos que deben estar en su lugar para apoyar y proteger el
organización.
Este capítulo analiza los factores críticos de éxito al adquirir sistemas o servicios de terceros.
vínculos, incluido el establecimiento de una estrategia, el seguimiento de un proceso de adquisición formal y el aprendizaje
términos y problemas del contrato de adquisición. Este capítulo también explica la gestión del servicio y las expectativas.
ciones para una asociación eficaz entre organizaciones y proveedores. Todo esto ayuda a garantizar que
el valor esperado es efectivamente entregado por el contrato y el proveedor. Outsourcing IT, discutido
a continuación, se refiere a la contratación de una empresa externa para manejar todo o parte del proceso de TI de una organ
ing actividades. Es una solución comercial viable, estratégica y económica que permite a las organizaciones
centrarse en lo que hacen mejor (es decir, competencias básicas) y dejar las actividades de procesamiento de TI (por ejemplo
345
Página 372
procesamiento, etc.) a empresas informáticas calificadas. Por último, la participación y los procedimientos de auditoría de T
cuando se examinan las adquisiciones de sistemas, así como los servicios de TI subcontratados.
Estrategia de adquisición de sistemas

Es importante contar con una estrategia que ayude a los departamentos con la selección, compra y,
si corresponde, implementación de sistemas relacionados con la tecnología (es decir, hardware, software, servicios).
El objetivo de esta estrategia es garantizar que los sistemas a adquirir (1) se alineen con los objetivos y
metas de la organización; (2) se integran bien y son compatibles con el software y la tecnología existentes
infraestructura energética; y que (3) den como resultado un rendimiento positivo de la inversión.
La clave para obtener valor para las organizaciones es establecer una asociación de beneficio mutuo con el
vendedores). Contratos que no generan ganancias para el proveedor ni ayudan a las organizaciones a cumplir con los
objetivos de ness están condenados al fracaso. Una vez que se establece la asociación, ambas partes deben
buscando oportunidades adicionales de beneficio mutuo y una relación simbiótica. Por otro lado, si el
la relación está fallando y no es posible ganar-ganar debido a ineficiencias con el proveedor, etc.
entonces debe haber una estrategia de salida de la relación que permita que el valor continúe con un
nuevo proveedor con costos de transición minimizados.
Proceso de adquisición de sistemas

Se ha escrito mucho en esta área. El proceso de adquisición del sistema debe incluir la identificación
tificación y análisis de soluciones alternativas que se comparan cada una con el negocio establecido
requisitos. En general, el proceso de adquisición consta de lo siguiente:
1. Definición de los requisitos del sistema

2. Identificación de alternativas
3. Realización de un análisis de viabilidad
4. Realización de un análisis de riesgos
5. Realización del proceso de selección
6. Adquirir el software seleccionado
7. Completar la aceptación final
Definición de requisitos del sistema

Uno de los mayores desafíos en la adquisición de cualquier sistema de información es definir sus requisitos.
Los requisitos del sistema describen las necesidades u objetivos del sistema. Ellos definen el problema como
resuelto, los objetivos del sistema y del negocio, los procesos del sistema que deben cumplirse y los entregables y
expectativas para el sistema. Los requisitos del sistema incluyen definir la información que se proporciona
al sistema
ción a procesar,
esperada fuera dellasistema.
información
Cadaarequisito
procesar debe
dentro del sistema,
definirse y la información
claramente para que las brechas posteriores en
Se evitan las expectativas.
Los requisitos del sistema se pueden capturar entrevistando a la gerencia y a los que se espera que utilicen
la información producida por el sistema para comprender sus expectativas. Recopilación de requisitos
también se puede lograr mediante:
Página 373
Adquisición, gestión y subcontratación ◾ 347
◾ Inspeccionar los sistemas existentes.

◾ Revisión de informes y formularios electrónicos y en papel relacionados.
◾ Observar los procesos comerciales relacionados.
◾ Reunirse con la gerencia de TI y el personal de soporte con respecto a sus expectativas y limitaciones
para implementar y apoyar el sistema.
◾ Investigar otras empresas de una industria relacionada, de tamaño similar y con una
entorno técnico amplio para identificar las mejores prácticas y lecciones aprendidas.
Un documento de requisitos del sistema registra formalmente las expectativas del sistema y,
incluye la siguiente información:
◾ Usuarios previstos. Los usuarios del sistema incluyen aquellos que realmente interactúan con él, así como
aquellos que utilizan la información que produce.
◾ Alcance y objetivos. El alcance debe ser "holístico", incorporando tanto el entorno técnico
ambiente, así como una perspectiva empresarial.
◾ Enunciado del problema. Una descripción del problema que debe resolver el sistema.
◾ Objetivos del sistema. Asegúrese de incluir metas y objetivos tanto técnicos como comerciales.
perspectiva.
◾ Análisis de viabilidad. Define las restricciones o limitaciones del sistema desde un punto de vista técnico y
puntos de apoyo empresarial. La viabilidad debe evaluarse en las siguientes categorías: económica,
técnicos, operativos, horarios, legales o contractuales y políticos. La viabilidad puede incluir
aquellas cosas que son tangibles, intangibles, únicas o recurrentes.
◾ Otros supuestos . Expectativas adicionales hechas con respecto al sistema, como el cumplimiento
con las prácticas comerciales existentes.
◾ Funciones esperadas del sistema . Funciones anticipadas del sistema que se proporcionarán, como autorizar
pagos y proporcionar el estado de la cuenta.
◾ Atributos del sistema . Atributos como facilidad de uso, tolerancia a fallas, tiempo de respuesta e integración
ción con las plataformas existentes.
◾ Contexto o entorno en el que se espera que funcione el sistema. Esto incluye una descripción de
el sistema que se espera que encaje o interactúe con el entorno (por ejemplo, contexto de la industria,
cultura empresarial, entorno técnico, etc.).
Identificación de alternativas
Existen muchas opciones para adquirir soluciones de sistema (es decir, software), que incluyen cualquier combinación
lo siguiente: producto listo para usar, paquete de proveedor comprado, contratación para el desarrollo
Opción o desarrollo del sistema internamente, o subcontratación de otra organización. Referirse a
Figura 13.1 para descripciones de estas opciones.
Una política de abastecimiento define dónde se adquirirán los sistemas o servicios de TI. Por ejemplo,
En un modelo centralizado de servicios compartidos, las unidades de negocio deben comprar en el
grupo central de TI. Este enfoque permite que TI estandarice las soluciones tecnológicas y
tamaño / escala de edad para la contratación. Puede haber situaciones en las que el grupo central de TI no pueda
proporcionar un sistema o servicio solicitado. En este caso, es necesario que exista un proceso para
soluciones de origen a través de un tercero. Aunque se pueden utilizar sistemas / servicios de terceros,
Es importante que TI gestione las adquisiciones y la relación para garantizar el cumplimiento de
normas internas.
Página 374
Figura 13.1 Opciones de adquisición del sistema
Adquisición del sistema

Opción Descripción
Fuera de la plataforma La compra de productos disponibles comercialmente requiere que la organización

Producto para adaptarse a la funcionalidad del sistema. Esta adaptación empresarial
proceso significa que la organización necesitaría personalizar el
producto de software, y posteriormente mantener esas personalizaciones
dentro de los procesos que se han modificado y cambiado. los
Las ventajas de usar productos estándar son una implementación más corta
tiempo, uso de tecnología probada, disponibilidad de conocimientos técnicos de
fuera de la empresa, disponibilidad de mantenimiento y soporte, y
costos más fáciles de definir. Las desventajas incluyen incompatibilidad
entre las capacidades del sistema empaquetado y la empresa
requisitos, dependencia a largo plazo de un proveedor para el mantenimiento y
soporte, requisitos específicos de hardware o software y limitaciones
sobre el uso o personalización del software.
Comprado Los proveedores desarrollan sistemas empaquetados para una amplia distribución que satisfacen un
Paquete de proveedor Problema comercial genérico. Por ejemplo, un sistema de nómina es algo
genérico para la mayoría de las organizaciones. A menudo, un sistema de paquete comprado
puede satisfacer las necesidades comerciales por mucho menos que desarrollar un sistema
internamente. Si hay varios sistemas de paquetes disponibles, las organizaciones
Desarrollar una solicitud de propuesta que defina los requisitos del sistema.
y solicita la solución del proveedor a esos requisitos.
Luego, las organizaciones sopesan qué tan bien cada sistema de paquetes cumple con
requisitos comerciales y si tienen sentido. Al seleccionar
un paquete de proveedor comprado, las organizaciones deben considerar
siguiendo:
• Estabilidad de la empresa proveedora

• Volatilidad de las actualizaciones del sistema
• Base de clientes existente
• Capacidad del proveedor para brindar soporte
• Hardware o software necesario para respaldar el sistema del proveedor
• Modificaciones necesarias del software base
Aunque los sistemas de paquetes de proveedores comprados pueden parecer menos

costoso de implementar que desarrollar un nuevo sistema internamente, no
son riesgos a considerar antes de seleccionar esta opción. Un sistema empaquetado
puede no satisfacer la mayoría de las necesidades comerciales, lo que resulta en
extensas modificaciones o cambios en los procesos comerciales. Además, cualquier
Las versiones futuras de este sistema pueden requerir una programación extensa para
reequipar todo el código específico de la empresa. Porque los sistemas empaquetados
son genéricos por su naturaleza, la organización puede necesitar modificar sus
operaciones comerciales para que coincidan con el método de procesamiento del proveedor.
Los cambios en las operaciones comerciales pueden ser costosos debido a la capacitación y la
Los nuevos procesos pueden no encajar en la cultura de la organización u otros
procesos.
( Continuacion )
Página 375
Figura 13.1 ( continuación ) Opciones de adquisición del sistema
Adquisición del sistema

Contratado o El desarrollo contratado requiere que la organización adquiera

En casa personal para desarrollar un nuevo sistema o personalizar un sistema existente
Desarrollo según las especificaciones de la empresa. Contratación para el desarrollo de sistemas
puede proporcionar un mayor control sobre los costos y la implementación
horarios, apalancamiento legal y financiero sobre el contratista, adicionales
experiencia técnica y la capacidad de adherirse a las políticas de la empresa,
procesos y estándares. Desventajas asociadas a la contratación
para el desarrollo incluyen mayores costos laborales en comparación con
personal interno, rotación del personal contratado, viabilidad comercial del
empresa contratada, exclusión de mantenimiento en costes de desarrollo,
y falta de comprensión organizativa por parte del contratista.
Los sistemas desarrollados internamente (es decir, software) se generan internamente
por la organización. Por ejemplo, las organizaciones desarrollan software
"Interno", ya sea porque no existe tal software (o similar
versiones) disponibles en el mercado, o porque la organización quiere
para personalizar el software en función de necesidades específicas. Otro
La ventaja del software desarrollado internamente es que más tarde puede convertirse
disponible para uso comercial a discreción del desarrollo
organización.
Subcontratación de Muchas empresas optan por subcontratar la funcionalidad del sistema de

Otro otra organización. La subcontratación permite a la empresa costear
Organización permanecer efectivamente enfocados en sus competencias básicas y rápidamente
responder a las necesidades comerciales y aprovechar la experiencia
de otra organización. La subcontratación proporciona un mayor control sobre
costos sin la necesidad de adquirir o mantener hardware, software,
y personal relacionado. Sin embargo, los sistemas de subcontratación aumentan la dependencia de
el subcontratista, limita la empresa a lo que proporciona el
subcontratista, y disminuye la capacidad de la empresa para adquirir
experiencia y conocimientos relacionados. La subcontratación se analiza en más
detalles más adelante en el capítulo.
Adaptado de Senft, S., Gallegos, F. y Davis, A. 2012. Control y tecnología de la información

Auditoría . Boca Ratón: CRC Press / Taylor & Francis.
Realización de un análisis de viabilidad

Un análisis de viabilidad define las restricciones o limitaciones de cada alternativa desde un punto de vista técnico.
así como una perspectiva empresarial. El análisis de viabilidad incluye las siguientes categorías: económico,
técnicos, operativos, legales o contractuales y políticos.
◾ El análisis de viabilidad económica proporciona una justificación de costo-beneficio. Los gastos de un sistema
incluyen adquisiciones, puesta en marcha, problemas específicos del proyecto e impacto en las operaciones. Incluye
costos únicos y recurrentes. La muestra de costos incluye lo siguiente: consultores, puesta en marcha
infraestructura, personal de apoyo, software de aplicación, contratos de mantenimiento, formación,
comunicaciones, conversión de datos y arrendamientos. Los beneficios incluyen reducción o evitación de costos, erro
Página 376
reducción, mayor velocidad, mejores decisiones de gestión, mejor respuesta a los negocios
necesidades, información oportuna, flexibilidad organizacional mejorada, mayor eficiencia y mejor
utilización de recursos.
◾ La viabilidad técnica analiza la viabilidad técnica del sistema propuesto. Evalúa
la coherencia del sistema propuesto con la estrategia técnica de la empresa, infraestructura
cultura y recursos. Responde a la pregunta de si la organización tiene los recursos para
instalar y dar soporte a la solución. La viabilidad técnica evalúa si la empresa tiene el
hardware, software y recursos de red necesarios para soportar la aplicación, así como
si proporciona confiabilidad y capacidad de crecimiento. También evalúa la experiencia técnica
requisitos y los compara con los proporcionados por la organización.
◾ La viabilidad operativa examina qué tan bien el sistema propuesto resuelve los problemas comerciales o
brinda oportunidades al negocio. También evalúa el alcance de los cambios organizacionales.
necesarios para acomodar el sistema. Estos cambios pueden incluir personal, negocios
procesos y productos o servicios ofrecidos.
◾ La viabilidad legal y contractual revisa cualquier obligación legal o contractual relacionada asociada
atado con el sistema propuesto. Las restricciones legales incluyen la ley federal o estatal, así como
regulaciones relacionadas con la industria. Además de las nuevas obligaciones contractuales introducidas por el
nuevo sistema, los contratos existentes también se revisan para garantizar que no existan
compromisos que regulen la instalación o uso del sistema propuesto. Consejero legal
debe participar en este proceso y es uno de los puntos críticos que deben revisar los auditores de TI.
Tenga en cuenta que el tema subyacente es la protección de la empresa y el establecimiento de la
proceso de reparación en caso de que el contratista no cumpla o no cumpla lo prometido. Organizaciones
Si busca asistencia en esta área debe consultar a su asesor legal o una organización cuya
los miembros se especializan en esta área.
◾ La viabilidad política evalúa cómo la organización interna aceptará el nuevo sistema. Esta
incluye una evaluación de la conveniencia del sistema dentro de la organización, así como su
encajar con la cultura corporativa de la organización.
Realización de un análisis de riesgos

Un análisis de riesgos revisa la seguridad del sistema propuesto. Incluye un análisis de seguridad
amenazas y posibles vulnerabilidades e impactos, así como la viabilidad de otros controles que
se puede utilizar para reducir los riesgos identificados. Los controles incluyen métodos sistemáticos o automatizados como
así como pistas de auditoría. Los riesgos, como se discutió en otros capítulos de este libro, afectan los objetivos de control en
las áreas de confidencialidad y privacidad de la información, integridad y precisión de los datos, tiempo
nidad de la información para la toma de decisiones, capacidad de acceder al sistema, así como organización del personal
ción y conocimientos necesarios para apoyar el sistema.
Realización del proceso de selección

El proceso de selección incluye identificar la mejor combinación entre las alternativas disponibles y la
requisitos identificados. Según el estado de la subcontratación, servicios compartidos,
and Operations Industry Survey Report, los tres principales criterios de selección para un servicio externo
proveedor son: retorno de la inversión (21%), resultados comerciales (16%) y automatización (11%) (nota
que el retorno de la inversión, no el costo, era la consideración más importante para los compradores). La encuesta
También mostró que las organizaciones más pequeñas dan más importancia a los criterios de selección tradicionales como
experiencia en la industria y calidad del servicio que los resultados comerciales y la automatización.
Página 377
Las actividades para seleccionar un proveedor de servicios externo comienzan con la solicitud de información para un
propósito específico seguido de la solicitud de propuestas a los proveedores interesados. El proceso termina con
evaluar las propuestas en términos de los requisitos identificados y seleccionar las mejores disponibles
alternativa (proveedor). El proceso de selección debe estar estructurado para asegurar que el proceso
ser completado diligentemente y de manera oportuna. Si se hace correctamente, el proceso de selección promueve
buy-in para la solución seleccionada. El proceso de selección se describe en el Cuadro 13.2.
Figura 13.2 Descripción del proceso de selección de proveedores
Evaluación
Solicitud de Solicitud de
y
información propuesta
selección
Proceso de selección
Actividad Descripción
Solicitud de Una RFI busca información de los proveedores para un propósito específico. Sin embargo,
Información (RFI) ni la empresa ni los proveedores están obligados por la respuesta
a la RFI. El RFI sirve como herramienta para determinar las alternativas o
alternativas asociadas para satisfacer las necesidades de la organización. Una RFI
a menudo pide a los proveedores que respondan a preguntas que ayudarán al
organización para obtener información adicional relevante. Información
de la RFI se puede utilizar para preparar una solicitud de propuesta.
Solicitud de Una RFP es un documento que especifica lo mínimamente aceptable

Propuesta (RFP) requisitos (funcionales, técnicos y contractuales), así como la
Criterios de evaluación utilizados en el proceso de selección. Una RFP ofrece flexibilidad
a los encuestados para definir o explorar más a fondo la solicitud
requisitos. Las RFP pueden dar lugar a una compra o una negociación continua.
Los proveedores potenciales reciben copias de la RFP y están
solicitó presentar propuestas en una fecha determinada. Después de que un proveedor
presentó una propuesta, la respuesta no se puede cambiar. La RFP
debe comunicarse a tantos posibles licitadores como sea posible.
Debe contener los criterios de selección que se utilizarán. El criterio
debe escribirse con suficiente detalle para evitar cualquier
malentendidos o malas interpretaciones. Cualquier criterio específico que
influencia la selección debe aparecer en la RFP. La RFP también debe
describir los miembros del comité de selección.
Todas las preguntas de los licitadores deben responderse por escrito y
disponible para todos los postores. Deben evitarse las respuestas verbales a las preguntas.
Todas las preguntas deben recibirse con tiempo suficiente antes de la
plazo para que las respuestas se puedan incorporar a la propuesta. Público
reuniones como las "conferencias de licitadores" se utilizan como un medio para recibir
y responder a las preguntas de todos los posibles postores. Lo básico
Los componentes de una RFP son:
• Información de antecedentes sobre la empresa, el problema comercial y

el entorno informático. También puede incluir resultados de cualquier
evaluación de necesidades realizada.
( Continuacion )
Página 378
Figura 13.2 ( continuación ) Descripción del proceso de selección de proveedores
Proceso de selección
Actividad Descripción
• Programa de fechas importantes, como cuando la RFP del proveedor

la respuesta es debida, cuando se espera la decisión, cuando la
se espera la compra y cuándo se espera la implementación.
• Nombres de contacto y fuentes para responder preguntas para la RFP.
• Instrucciones para formatear la respuesta a la RFP. Algunas RFP
incluir una descripción explícita de lo que el proveedor debe y
no debe incluir en su respuesta.
• Se buscan requisitos específicos.
• Requisitos técnicos del sistema, como especificaciones para un
sistema operativo o un entorno de red.
• Lista de documentos necesarios como archivos adjuntos, como informes de muestra
y lenguaje de contrato estándar.
• Requisitos adicionales para el proceso de selección, como proveedor
presentaciones, demostraciones de proveedores o instalación in situ y
pruebas.
Los componentes enumerados anteriormente deben seguirse al pie de la letra antes de

se puede realizar el siguiente paso. Si no se sigue como lo ha hecho la empresa
especificado, una "protesta de oferta" podría ser presentada por uno de los posibles
proveedores. Nuevamente, esta es otra auditoría, administración o asesoría legal.
punto de revisión antes de que pueda comenzar el proceso de evaluación.
Evaluación y Un comité de selección de una o más partes interesadas clave evalúa

Selección presentó propuestas utilizando una lista de criterios de selección objetivos. Una lista de
El criterio de selección objetivo se utiliza como medio para identificar el
mejor coincidencia entre las características y la funcionalidad del producto y la
requisitos identificados. La base de los criterios de selección es el usuario
y requisitos del sistema. Las características y la funcionalidad son normalmente las
factores más importantes en el proceso de toma de decisiones.
Los criterios de selección también pueden incluir la evaluación de la consistencia de la
propuesta con la estrategia comercial y de TI de la empresa, la amplitud de
los productos y servicios del proveedor, la experiencia relevante del proveedor,
atención al cliente del proveedor, escalabilidad de la solución, proveedor
viabilidad, costo total de propiedad, integración y capacidades de crecimiento,
y confiabilidad.
Los participantes en el proceso de selección a menudo incluyen representantes de
partes interesadas clave, como la administración y los usuarios anticipados, así como
el departamento de TI. El comité de selección debe estar compuesto por
representantes que son imparciales con cualquier proveedor o solución, han
conocimiento de las mejores prácticas y conocimiento del mercado. Sin embargo,
Los participantes no deben tener ningún conflicto de intereses y deben
firmar una declaración antes de formar parte del comité de selección,
indicando que no lo hacen. Si lo hacen, alguien que conozca
las cualificaciones justificadas y no tienen un conflicto de intereses deben
sustituirlos.

Página 379
Adquirir software seleccionado

Una vez que se ha seleccionado una solución técnica, el proceso de adquisición ayuda a garantizar que el
se negocian los términos y condiciones. Uno de los procesos integrales en cualquier proyecto es la contratación
servicios, hardware y software. En la mayoría de los casos, las organizaciones consideran si deben
o comprar sistemas. En cualquier caso, generalmente se requiere la contratación de servicios externos. Dependiente
según el alcance del servicio, se debe preparar una solicitud de propuesta formal u otro documento de requisitos
para solicitar ofertas competitivas. Los requisitos deben incluir niveles de servicio con sanciones contractuales.
y seguimiento de métricas / criterios de éxito.
El proceso de adquisición parece simple, pero en realidad es el más complicado de todos los procesos de adquisición.
pasos. Requiere que se estipulen y acuerden el precio y las condiciones de compra. Estas
los acuerdos toman la forma de contratos.
Al adquirir software, los gerentes de TI se quejan de tarifas de licencia impredecibles, presionados
métodos de venta, soporte técnico deficiente y precios poco claros para las tarifas de mantenimiento continuo.
Los contratos de software y los acuerdos de licencia se utilizan para documentar los acuerdos de desarrollo.
ment, marketing, distribución, licenciamiento, mantenimiento o cualquier combinación. Los contratos pueden especificar
un precio fijo o un precio basado en tiempo y materiales. Contratos basados en tiempo y estado de materiales
que los honorarios cobrados son directamente atribuibles a gastos reales de tiempo (por hora) o materiales.
Estos contratos suponen un mayor riesgo financiero para el comprador si la definición inicial de precio, el alcance,
o los requisitos deseados no son claros o están mal definidos. Los términos y condiciones del contrato normalmente
Incluya lo siguiente:
◾ Una definición funcional del trabajo a realizar.

◾ Especificaciones para diseños de entrada o salida, como interfaces, pantallas o informes.
◾ Descripción detallada del hardware necesario.
◾ Descripción de los sistemas o herramientas de software necesarios para su desarrollo o implementación.
◾ Términos o limitaciones con el uso de cualquier derecho de marca o copyright relacionado.
◾ Requisitos para la conversión o transferencia de datos.
◾ Rendimiento o capacidad del sistema, como velocidad, rendimiento o almacenamiento.
◾ Procedimientos de prueba utilizados para identificar problemas y los resultados esperados para definir la aceptación.
La información y los requisitos del sistema sirven como base para definir las pruebas de aceptación.
◾ Dotación de personal del proveedor y calificaciones específicas.
◾ Protocolos de contacto y relación entre comprador y proveedor.
◾ Programas esperados para el desarrollo, implementación y entrega.
◾ Métodos para proporcionar informes de progreso, como reuniones o informes.
◾ Definición de entregables, que incluye una descripción clara de cada artículo a entregar
o proporcionado por el proveedor, cuándo debe ser entregado, y las consecuencias por no
entregables.
◾ Criterios explícitos para definir la aceptación de cada entregable, así como para la aceptación final.
◾ Requisitos y expectativas de instalación.
◾ La documentación que se espera que sea proporcionada al proveedor o por el proveedor, así como cualquier
derechos de propiedad intelectual necesarios para mantener o personalizar la documentación.
◾ Se espera que la formación se proporcione como parte del producto o servicio.
◾ Cualquier garantía o mantenimiento aplicable, incluidas las disposiciones para versiones futuras actualmente
en desarrollo.
◾ Cualquier requisito de indemnización o recuperación por pérdidas, como seguros o fianzas
requisitos.
Página 380
◾ Una declaración de apoyo futuro que se proporcionará, así como los costos anticipados.
◾ Definición clara de propiedad o licencia de derechos de autor y patentes relevantes.
◾ Términos y condiciones relacionados con la confidencialidad o secretos comerciales para cualquiera de las partes.
◾ Términos o limitaciones relacionados con el personal que cambia de empleador de una parte a otra (por ejemplo,
personal de asalto, etc.).
◾ Descripción de las condiciones de pago.
◾ Proceso para aceptar cambios en la definición del contrato, como cambios en los términos, alcance o
entregables.
Otras consideraciones, específicamente para contratos y licencias de software, también deben abordar la
siguiendo:
◾ Flexibilidad y elección de actualizaciones y actualizaciones. Algunos contratos especifican las actualizaciones necesari
para recibir actualizaciones o mantenimiento.
◾ Acuerdos de nivel de servicio (SLA) para definir expectativas de soporte y mantenimiento.
◾ Costos anuales de mantenimiento. Dichos costos de mantenimiento deben fijarse en el momento de la compra.
y no debe variar.
◾ Disposiciones para proteger a la empresa contra problemas imprevistos como software
interoperabilidad.
◾ Derechos de propiedad intelectual para modificaciones. Al cliente no se le pueden otorgar los derechos para
modificaciones.
◾ Términos y condiciones para las opciones de terminación, como qué proceso de transferencia tomará
lugar cuando finaliza la licencia, la duración del período de transición y los impactos del
terminación.
◾ Cláusulas de cesión que requieren consentimiento. Las cláusulas de cesión permiten al proveedor segregar
los pagos del cliente del proveedor del servicio. Bajo una cláusula de cesión, el
El proveedor puede transferir las obligaciones financieras del cliente a otra empresa o servicio continuo.
componentes a un tercero. Con el pago y el servicio separados, la motivación del proveedor
Se puede reducir el cumplimiento de los términos del contrato.
◾ Verificación de cualquier restricción de exportación o importación por parte de los clientes. Específicamente, la export
de la tecnología especificada debe estar permitida por las restricciones legales de EE. UU. y la importación
permitido por el gobierno extranjero. La licencia debe especificar la responsabilidad de los costos
o deberes.
◾ Aprobaciones reglamentarias que pueden ser necesarias. Algunos gobiernos, como Japón, exigen que
aprueban la licencia. Si no se solicita la aprobación, la licencia puede considerarse nula.
La licencia debe especificar qué parte es responsable de obtener la aprobación.
◾ Revisión de las leyes de competencia o antimonopolio para garantizar el cumplimiento de cualquier
requisitos.
◾ Consideración
para minimizar
deeltipos
riesgo
de de fluctuaciones
cambio en los
de moneda. Lostipos
tiposdedecambio.
cambio deben acordarse en el contrato.
◾ En el caso de subcontratación, especificación en el contrato para los intereses financieros y legales
en el software de la empresa que ahora cuenta con el apoyo del subcontratista. Por ejemplo, en algunos
casos, la licencia de software puede transferirse al subcontratista, que requerirá volver a obtener la licencia de su
propio software si la empresa decide posteriormente interrumpir la subcontratación. La otra opcion es
Permitir que el subcontratista utilice el software, siendo la empresa responsable de todos
acuerdos de licencia.
Página 381
Completando la aceptación final

Se debe acordar y definir un plan de aceptación en el contrato. Este plan define los términos
y condición para la aceptación. Normalmente, el pago final se retiene hasta que todas las pruebas de aceptación hayan
completado y el software y el equipo cumplen con todas las especificaciones del contrato.
La adquisición de tecnología depende de otros procesos clave y debe integrarse para operar
efectivamente. Por ejemplo, los dispositivos adquiridos deben integrarse con la arquitectura de infraestructura existente.
y dependencias del proyecto vinculadas a la entrega de componentes. Además, el ciclo de vida de los adquiridos
dispositivos no termina con el proceso de adquisición. Los activos deben estar instalados, asegurados, rastreados,
mantenidos y eliminados correctamente.
Gestión De Servicios
El proceso de gestión del servicio comienza una vez que se firma un contrato y ayuda a garantizar que los proveedores
estar a la altura de sus compromisos. El uso de recursos externos proporciona flexibilidad y escalabilidad mediante palanca
envejecimiento de la experiencia y el personal de proveedores externos para las necesidades de personal temporal para el de
proyectos. También existe la oportunidad de reducir los costos de desarrollo mediante la subcontratación del programa.
trabajando con proveedores offshore con procesos de desarrollo maduros y tarifas laborales económicas. Allí
son una variedad de modelos de abastecimiento, desde la entrega interna hasta la subcontratación completa. Todos los mode
procesos internos para gestionar los niveles de servicio, los costes y el riesgo.
El proceso de gestión de servicios para una organización incluye servicios de TI definidos; SLA;
servicios de diseño y precios; compromiso y entrega de servicios; y mediciones de servicio para rastrear
actuación.
Servicios de TI definidos
La definición de servicios requiere que la organización considere qué servicios son importantes desde un cliente.
perspectiva del consumidor. Por ejemplo, la función financiera depende de la disponibilidad del
sistemas contables. Los usuarios de finanzas no están realmente interesados en la disponibilidad de la plataforma, aunque es
puede ser un aspecto importante de la aplicación de contabilidad. La aplicación contable
solo funciona si todos los componentes involucrados en la entrega de la aplicación funcionan. El hardware del cliente y
el software, los componentes de red, el hardware y software del servidor y la base de datos deben
todos funcionan bien juntos para entregar la aplicación de contabilidad al usuario final. De un cliente
perspectiva, la medición de la disponibilidad de un extremo a otro de la aplicación contable es importante
tant. Desde una perspectiva de TI, cada una de las plataformas individuales debe estar disponible para ofrecer el
servicio esperado del cliente. Los procesos que intervienen en la entrega de la disponibilidad de la plataforma
incluir todos los aspectos de TI.
La prestación de servicios de TI de alta calidad depende de la entrega de aplicaciones de alta calidad.
y todos los
control, procesosrecuperación
seguridad, que intervienen
anteen la gestión
desastres, de lasde
gestión operaciones de TI:
proveedores, etc. gestión de capacidad,
Otro factor cambioen
de complicación de
medir y entregar servicios de TI es la dependencia de proveedores de servicios de terceros,
redes, hardware y software. Con toda esta complejidad, la prestación de servicios de TI de alta calidad es
muy retador.
Una organización con un gran volumen de aplicaciones hace que la tarea de medir el servicio sea uniforme
más difícil. Probablemente no sea rentable medir todas las aplicaciones de una organización;
por lo tanto, tiene más sentido medir aplicaciones clave seleccionadas. Estos y otros factores deben
Página 382
negociarse con los clientes identificados, teniendo en cuenta que será necesario realizar concesiones
sobre el valor entregado en comparación con el costo.
Acuerdos de Nivel de Servicio

Un SLA es un acuerdo formal entre un cliente que requiere servicios y la organización que
responsable de proporcionar esos servicios. A continuación se muestran los términos básicos definidos relacionados con los
◾ Servicio . Un conjunto de entregables que pasa entre un proveedor de servicios y un consumidor de servicios.
◾ Nivel . La medición de los servicios prometidos, los servicios prestados y el delta entre los
dos.
◾ Acuerdo . Contrato entre dos entidades: la que proporciona el servicio y el destinatario.
Los SLA deben incluir una definición de los servicios, el nivel de calidad esperado, cómo será el servicio.
medida, la capacidad planificada, el costo del servicio, los roles y responsabilidades de las partes,
y un proceso de recurso por incumplimiento. Para un acuerdo de servicio interno, el rendimiento puede
vinculado a la compensación (por ejemplo, bonificaciones, etc.). Los acuerdos externos pueden implicar el pago de una mult
o compensación por mal desempeño.
Es importante involucrar al cliente en el proceso de definición del nivel de servicio para ayudar a obtener
acuerdo y buy-in. La gestión de la organización hará concesiones entre la calidad del servicio
y costo. Estas decisiones deben comunicarse a toda la organización para establecer expectativas en
todos los niveles. De lo contrario, los resultados de satisfacción del cliente pueden reflejar expectativas poco razonables fren
niveles de servicio de TI acordados.
Se pueden establecer SLA entre TI y sus clientes, operaciones y grupos de aplicaciones, y
entre proveedores y TI. Un acuerdo de nivel de servicio al cliente (CSLA) abarca todos los
subservicios que se proporcionan tanto interna como externamente para brindar los servicios que necesita el
cliente como se definió anteriormente. Un acuerdo de nivel operativo (OLA) entre operaciones y aplicaciones
Los grupos de aplicación definen los servicios operativos subyacentes necesarios para entregar proyectos y aplicaciones.
al cliente en virtud de la CSLA. Los SLA del proveedor definen los servicios requeridos por las operaciones,
cationes o usuarios finales para entregar de acuerdo con la CSLA. Estos tipos comunes de SLA son
explicado en la figura 13.3.
Servicios de diseño y precios

El diseño del servicio puede ser bastante complicado, dependiendo del desglose de la organización y
los componentes necesarios para soportar una aplicación. Una vez definidos los servicios, el
las funciones y los procesos deben asignarse a cada uno de los servicios. En el nivel más bajo, la organización de TI
Las organizaciones suelen separar los costos en centros de costos alineados con los gerentes individuales. Estos cuestan
Los centros deberán estar alineados con los servicios en su totalidad o como un porcentaje basado en una asignación del
tiempo empleado o alguna otra medida apropiada. Por ejemplo, un grupo de operaciones puede gastar
20% de su tiempo apoyando el entorno del cliente, 20% apoyando el entorno de mainframe,
30% respalda el entorno distribuido y 30% respalda el entorno de red. por
Por ejemplo, desarrollar los precios para el alojamiento de aplicaciones de mainframe requerirá la agregación de
todos los costos que implica el soporte del entorno de mainframe. Alojamiento de aplicaciones de mainframe
puede incluir ingeniería, respaldo, archivo, recuperación, recuperación ante desastres, monitoreo del desempeño,
gestión de capacidad y aprovisionamiento.
Página 383
Figura 13.3 Tipos comunes de acuerdos de nivel de servicio
Nivel de servicio
Acuerdo Descripción
Cliente Un CSLA es un acuerdo formal entre TI y la organización de usuarios. Eso

Nivel de servicio abarca todos los subservicios que se proporcionan tanto internamente como
Acuerdo externamente para brindar los servicios que necesita el cliente. El cliente
(CSLA) es un grupo de usuarios definido como el primer paso del proceso y suele ser un
función de la organización que es el usuario principal de una aplicación clave (por ejemplo,
finanzas, recursos humanos (RR.HH.), etc.). Es mejor tener la primaria
propietario de cada aplicación clave para obtener un acuerdo sobre los niveles de servicio y
precios. La organización de usuarios principal puede incluir los servicios de TI y
costo en servicios a sus clientes. Aunque es posible dividir el costo
de una aplicación compartida en grupos de usuarios separados, no es posible
proporcionan distintos niveles de servicio para la misma aplicación. Ejemplos de
los servicios al cliente incluyen:
• Servicios al cliente: escritorio, computadora portátil, dispositivos móviles, software, soporte,

etc.
• Servicios de almacenamiento: dispositivos de almacenamiento de acceso directo, red de área de almacenamiento,
cinta, etc.
• Servicios de redes: telecomunicaciones, datos, Internet, etc.
• Servicios de ERP: contabilidad, recursos humanos, adquisiciones, etc.
• Servicios de procesamiento comercial: fabricación, procesamiento de políticas, etc.
Niveles de servicio que se proporcionan a todos los grupos de usuarios (por ejemplo, personal
servicios informáticos, etc.) pueden tener que ser acordados a nivel de la organización.
Es posible ofrecer diferentes opciones de hardware, software y soporte
a los usuarios finales; sin embargo, esto puede resultar más costoso. Estandarización de hardware
software y soporte permite a una organización aprovechar la escala en
negociación y obtención de eficiencias de procesamiento. Estas son decisiones que
se realizan mejor a nivel de organización.
Nivel operativo Los OLA, ya sean formales o informales, definen los servicios subyacentes
Acuerdo requerido por los grupos de desarrollo y mantenimiento de aplicaciones para entregar
(OLA) los servicios de aplicaciones de un extremo a otro para los clientes. Un acuerdo formal
ayuda a establecer expectativas entre la aplicación y los grupos de operaciones
sobre la calidad del servicio; funciones y responsabilidades; capacidad esperada;
y en algunos casos, el costo del servicio. Ejemplos de servicios operativos incluyen:
• Servicios de alojamiento de aplicaciones de mainframe

• Servicios de alojamiento de aplicaciones distribuidas
• Servicios de alojamiento de aplicaciones web
• Servicios de almacenamiento, como DASD, SAN, cinta, etc.
• Servicios de redes, como telecomunicaciones, datos, Internet, etc.
Los servicios de almacenamiento y red se pueden proporcionar directamente al cliente.

sin combinar con otros servicios. También pueden aparecer en la
OLA para tener todos los servicios operativos subyacentes en un acuerdo para
propósitos de rendición de cuentas.
( Continuacion )
Página 384
Figura 13.3 ( Continuación ) Tipos comunes de acuerdos de nivel de servicio
Nivel de servicio
Acuerdo Descripción
Proveedor Una parte o la totalidad de un servicio puede ser proporcionado por un tercero a través de
Nivel de servicio subcontratación, cocontratación o contratación selectiva. Es importante alinear
Acuerdos los SLA de terceros a los SLA del cliente para evitar un
malentendido o mala interpretación del acuerdo. Por ejemplo,
Sería prácticamente imposible tener éxito si el SLA del proveedor
promete una disponibilidad del 95% y el SLA del cliente promete un 99%. A
gestionar con éxito los servicios proporcionados por un tercero, TI debe tener un
conocimiento sólido de los servicios que brinda, los servicios esperados
del tercero, y cómo funcionan los servicios internos y externos
juntos. Ejemplos de servicios de terceros incluyen:
• Mesa de servicio, soporte de escritorio, etc.

• Desarrollo o mantenimiento de aplicaciones
• Alojamiento de aplicaciones
• Detección de intrusiones
Para tener éxito, las organizaciones deben contar con procesos para
supervisar constantemente el cumplimiento de los niveles de servicio de todos los proveedores clave.
Dado que los servicios y gastos de terceros representan una parte significativa de TI
servicios y costos, vale la pena invertir en la gestión de terceros
prestación de servicios.

Detrás de los servicios al cliente hay una o más funciones o procesos de TI necesarios para brindar esos
servicios. Por ejemplo, diseñar un servicio ERP requiere agregar el mantenimiento de la aplicación ERP
costos más los costos del servicio de infraestructura subyacente más los costos generales.
Para complicar aún más el diseño del servicio, se proporcionan distintos niveles de servicio según la disponibilidad.
requisitos. Cuantas más opciones, más complejo es el modelo de servicio y más complicado
el modelo de precios y el proceso de medición resultante. La organización y la gestión de TI deben
comprender el costo / beneficio antes de implementar un modelo de servicio / precio complicado. El autor
recomienda mantener la estructura del servicio lo más simple posible para la implementación inicial. Más
Se puede agregar complejidad una vez que los procesos de gestión de servicios (por ejemplo, medición, etc.) estén maduros.
Hay algunos servicios que probablemente serán necesarios para todos los clientes según el
estrategia de servicio de la organización. Los servicios requeridos pueden incluir niveles mínimos de recuperación ante desa
seguridad,
algunos de gestión de riesgos
los conflictos en layfijación
gestión de
de precios
proyectos. Hacer queyestos
de proyectos servicios
servicios, seanson
ya que obligatorios
requeridosreduce
por la organización y
integrado en el modelo de servicios y precios. Es importante indicar explícitamente los servicios obligatorios
que se incluyen en el servicio o modelo de precios para mejorar la transparencia en los servicios de TI.
Compromiso y entrega de servicios

Un aspecto importante de la gestión de servicios es cómo se prestan los servicios a las organizaciones de usuarios.
ción. El servicio de aprovisionamiento es el primer punto de contacto con los usuarios y el punto de captura para su uso
información. Para brindar servicios al usuario final (por ejemplo, cliente, telecomunicaciones, etc.), el primer punto de conta
Página 385
prepara el escenario para brindar satisfacción al cliente. Adquisiciones, gestión de activos y servicio
Desk son procesos que dependen del suministro de servicios para funcionar correctamente. Obtención
Los procesos para los servicios al usuario final deben acordarse con las organizaciones de usuarios para garantizar que solo
Se proporciona hardware, software y acceso al sistema aprobados a los usuarios finales. El pro-
El proceso puede ser el desencadenante para la creación de información de usuarios y activos utilizada por seguridad, finanz
gestión, operaciones, gestión de servicios y la mesa de servicio para identificar usuarios y clientes
configuraciones.
Para el desarrollo y mantenimiento de aplicaciones, el punto de entrada a TI es la entrada al sistema.
tems el ciclo de vida del desarrollo, y los procesos maduros en esta área pueden hacer o romper la relación
Con el cliente. Se describieron la gestión de la demanda, la definición de requisitos y el control de cambios.
maldecido en capítulos anteriores. Nuevamente, estos procesos deben ser acordados entre TI y la organización.
gestión para asegurar la alineación con las reglas de enfrentamiento. Estos procesos son aún más
crítico en un entorno subcontratado donde las solicitudes de servicio deben ser aprobadas antes de incurrir
cargos. Existen soluciones automatizadas para ingresar, aprobar y rastrear los requisitos de la aplicación:
y solicitudes de servicio que se analizaron en capítulos anteriores.
Medidas de servicio
Las áreas que se miden obtienen el enfoque y tienden a mejorar como resultado. Centrándose solo en el cliente
El servicio puede conducir a una mejora en un área a costa del sacrificio de otros (por ejemplo, costo y seguridad,
etc.). Por eso es importante medir las cosas correctas. Según Gartner Group,
también es importante contar con diferentes medidas internas y externas. Las medidas internas mantienen la
Grupo de TI centrado en lo que deben hacer para alcanzar los niveles de servicio. Medidas externas (cliente)
debe centrarse en las cosas que le interesan al cliente.
Debido a que las funciones y procesos internos de TI impactan los servicios al cliente de diferentes maneras, es
importante alinear las medidas internas con los servicios al cliente externo. La medida interna de TI
Las garantías deben diseñarse para responsabilizar a los grupos individuales de entregar su porción.
del servicio.
También es importante coordinar la medición de los servicios de TI con la mejora de los procesos de TI y
métricas de gobernanza. Medir demasiados procesos para demasiados propósitos puede crear medidas
sobrecarga de ment. Aprovechar la misma información para múltiples propósitos es mucho más eficiente. Un poco
La planificación anticipada de qué medir y el uso de las mediciones contribuirá en gran medida a
Implementar un proceso de medición efectivo. Una vez decididas las medidas, el
es necesario identificar la fuente de la información. La fuente debe ser confiable y consistente
Asegúrese de que la medición se pueda entregar. Las reglas en torno a la medición también deben decidirse
y acordado por todas las partes. Tener una medida en la que no se confía es contraproducente.
Que medir
Qué medir dependerá de los servicios prestados y del nivel de calidad acordado. Es importante
para mantener cualquier programa de medición simple, ya que el costo de entregar mediciones más detalladas puede
superan con creces el beneficio. Sin embargo, la medición debe ser lo suficientemente granular para ayudar a identificar la ra
causa de los problemas y responsabilizar a las personas por su parte del servicio. Consideración
también debe darse al nivel de madurez en la organización de TI. Puede ser necesario comenzar
con medidas simples que se amplían a medida que madura la organización de TI. Los datos subyacentes
debe estar disponible para métricas más complicadas y la adquisición de los datos correctos debe ser
planeado de antemano.
Página 386
Control y auditoría de tecnologías de la información 360 ◾
Los servicios de aplicaciones suelen incluir el mantenimiento de aplicaciones existentes, realizar cambios y
mejoras a las aplicaciones existentes y creación de nuevas aplicaciones (es decir, proyectos). Como se discutio
antes, los clientes se preocupan por la disponibilidad de sus aplicaciones clave. Para determinar la disponibilidad, todos
Los componentes de una aplicación deben medirse para determinar la disponibilidad de un extremo a otro.
Los servicios de infraestructura incluyen la construcción y mantenimiento de plataformas operativas. La disponibilidad
medirse en la plataforma operativa (por ejemplo, mainframe, UNIX, Windows, Linux, etc.) o
nivel de entorno (por ejemplo, en línea, aplicación, base de datos, etc.). Las métricas de infraestructura dependerán de
los servicios prestados.
La determinación del porcentaje de disponibilidad requerido dependerá del objetivo de la organización.
tivos, función de la aplicación, tolerancia al riesgo y costo / beneficio de una mayor disponibilidad. Con
la complejidad de las aplicaciones y la tecnología actuales, aumentando la disponibilidad del 95% al 100%
sería costoso y tal vez incluso imposible.
Medir el éxito del proyecto incluye cumplir con el alcance, cronograma, presupuesto y
calidad. La medición del cambio podría incluir el costo promedio por cambio, el tiempo de entrega y la calidad.
La medición de la calidad podría incluir la cantidad de problemas / problemas, la gravedad, el retraso y el tiempo para resolv
El desafío con las métricas de calidad es que hay muchos factores que entran en un sistema de calidad que
puede no estar bajo el control del grupo de TI. Los problemas de calidad pueden surgir de una falla en el
parte del grupo de usuarios para definir los requisitos, validar la aceptación y capacitar a los usuarios sobre cómo
utilizar activamente el sistema. Es importante rastrear la causa subyacente de los problemas / problemas para poder
para identificar la causa raíz y atribuir solo aquellos problemas asociados con TI al SLA.
Una medida importante para los servicios de infraestructura y aplicaciones es el número de
cambios. Una gran cantidad de cambios puede indicar una falla por parte de los grupos de usuarios para
definir requisitos, una falla por parte del grupo de aplicaciones para comprender los requisitos o
implementar código de alta calidad, una falla del grupo de operaciones para administrar cuidadosamente el cambio en el
infraestructura, o un problema general con el proceso de control de cambios.
Cómo medir
Tan importante como qué medir es cómo medir. Cualquiera que sea el método seleccionado, debe
utilizado de forma coherente y claramente comunicada a las organizaciones de usuarios. Los siguientes son posibles
enfoques para medir el uso del procesador:
◾ Consumo pico . Este método mide el nivel más alto de consumo. Como hardware /
El software debe comprarse para soportar la capacidad máxima, alinea más estrechamente los costos con
sumption. Sin embargo, la organización debe decidir cómo medir y cobrar los picos.
versus consumo fuera de horas pico.
◾ Capacidad asignada . Este método mide los procesadores o la capacidad asignada a los grupos de usuarios.
o aplicaciones.
idad asignada aEl
lasdesafío viene
funciones delcon la medición
sistema. de entornos
Si se excluye compartidos
la capacidad y la capacidad
del sistema, solo la capacidad de producción
se mide y asigna. Sin embargo, ¿qué sucede durante el mes en que la contabilidad
los sistemas necesitan capacidad adicional para el procesamiento de fin de mes?
◾ Consumo medio . Este método mide la capacidad media o el consumo sobre
un período de tiempo. Este enfoque parece superar algunas de las limitaciones con el otro
dos métodos. Sin embargo, no fomenta la optimización de la carga de trabajo para minimizar el pico
carga de trabajo.
◾ La disponibilidad de un extremo a otro se basa en las interrupciones de los componentes, así como en los problemas /
las horas centrales de servicios . La disponibilidad de un extremo a otro se puede medir dividiendo la aplicación
Página 387
tiempo de inactividad por el tiempo de conexión disponible. Sin embargo, esto no tiene en cuenta el número
número de usuarios afectados. Un apagón temprano en la mañana puede tener un impacto mucho menor que un
interrupción en el uso pico durante el día. Una medida más significativa desde la perspectiva del cliente
tivo sería el número de usuarios afectados multiplicado por la cantidad de tiempo que el sistema
no está disponible. Multiplicado por el costo promedio por usuario puede dar un valor financiero aproximado.
impacto de una interrupción. Esta información se puede utilizar para determinar el costo / beneficio de
aumentar los niveles de servicio o considerar mejoras en los procesos.
Una herramienta común que se utiliza para reflejar muchos de estos son gráficos, tablas o tablas. Es muy importante que
Si dichos datos se analizan y muestran, la información sobre el período de tiempo y la fuente de datos se
proporcionado claramente. Además, cualquier anomalía o suposición debe comunicarse claramente, especialmente
si los datos están pronosticados o proyectados. Sin la comunicación adecuada, estas herramientas pueden
distorsionar los resultados y ser contraproducentes para la organización.
Herramientas de gestión de servicios

Hay muchas herramientas disponibles para ayudar a las organizaciones a implementar programas de gestión de servicios.
cesses. Se necesitan herramientas para capturar el rendimiento, las métricas de uso de las diversas plataformas y
consolidar e informar sobre toda esta información. Se requiere automatización para ofrecer un
proceso de medición y reporte. Muchas de las herramientas de gestión del rendimiento que utilizan los sistemas
Los programadores, operaciones y administradores de red también se pueden utilizar para medir la prestación de servicios.
ery. Ejemplos comunes de herramientas de administración de servicios incluyen: Encuestas de satisfacción del cliente y
Benchmarking.
Una encuesta de satisfacción del cliente es un buen ejemplo de una herramienta importante que se utiliza para medir la
calidad de los servicios prestados por TI. Puede haber varias encuestas de satisfacción del cliente para diferentes
diferentes servicios. Es posible que se le hagan preguntas a la alta dirección sobre el valor de la TI y que los usuarios finales
recibir preguntas sobre la satisfacción con la mesa de servicio y la disponibilidad de la aplicación.
La satisfacción de la alta dirección debe medirse por separado, ya que habrá diferentes objetivos.
tivas y preguntas. La alta dirección estará más centrada en el valor que ofrece TI. Esta
puede incluir la entrega de proyectos, la comprensión de TI de las necesidades comerciales, la entrega de aplicaciones y el so
puerto, rentabilidad, calidad del servicio y satisfacción general.
Las encuestas de satisfacción del cliente pueden incluir el tiempo para proporcionar solicitudes, el tiempo para el servici
escritorio para responder una llamada, satisfacción con la resolución de problemas y tiempo de respuesta del sistema. Usand
encuestas de satisfacción para medir el tiempo de respuesta del sistema, además de utilizar medidas técnicas, ayuda
para determinar si existe una brecha de expectativas. Esta información se puede utilizar en discusiones con
la gestión de la organización para aumentar el nivel de servicio esperado o mejorar la comunicación
ción a la población de usuarios.
Además de informar los resultados de la encuesta, se necesita un proceso de seguimiento para responder a las cuestiones
en la encuesta. Esta es una herramienta de comunicación importante y también puede ayudar a impulsar la satisfacción del c
facción. La satisfacción del cliente es en parte el resultado de las expectativas y solo la escucha activa puede impulsar
resultados. Ésa es otra razón por la que la satisfacción del cliente puede tener más que ver con la comunicación.
ción y la relación TI / organización que con los problemas reales del servicio.
El mayor desafío con la evaluación comparativa es encontrar una organización que sea de tipo similar,
tamaño y estructura con necesidades comerciales similares. Esto es particularmente difícil ya que todas las organizaciones
es diferente. Una organización puede ser una de las primeras en adoptar tecnología, mientras que organizaciones similares
pueden ser adoptantes tardíos. Estas diferencias pueden afectar las comparaciones de servicios y costos, por ejemplo, en
un ejercicio de evaluación comparativa.
Página 388
Los servicios de evaluación comparativa intentan alinear los costos y los servicios utilizando definiciones estándar de
elementos de servicio y costo. Esto hace que la evaluación comparativa sea una tarea costosa y que requiere mucho tiempo
La información oficial y las estructuras de servicios deben reformularse para alinearse con el índice de referencia. Incluso co
reexpresión de servicios y costos, la evaluación comparativa tendrá un valor limitado ya que puede haber razones válidas
hijos por la diferencia de costo con respecto al índice de referencia. Por ejemplo, una organizacin puede tener menos automa
ción y un mayor costo unitario compensado por operaciones manuales eficientes. Lo contrario podría ser cierto, alto
Automatización con bajo costo unitario combinado con operaciones manuales ineficientes. La conclusión es no
un punto de datos puede proporcionar información concluyente sobre la eficiencia o eficacia de los servicios de TI.
Otro problema que reduce el valor de la información de evaluación comparativa es que los resultados no
Ser los mismos servicios con los que están familiarizadas las organizaciones de usuarios. Esto hace que sea difícil de confirm
y comunicar que el costo unitario cargado a las funciones de usuario individuales se compara favorablemente
al punto de referencia. La ventaja de utilizar información de referencia externa es la independencia
fuente de datos de comparación. La información proporcionada al proveedor del índice de referencia debe ser auditada.
capaz de garantizar la credibilidad de los resultados. Hacer que la auditoría interna valide la presentación también puede
ser una buena forma de validar los resultados.
La evaluación comparativa puede ser una herramienta útil para evaluar el diseño, la calidad y el costo de los servicios de
Sin embargo, debido a las limitaciones, la evaluación comparativa debe considerarse como un insumo para evaluar
el costo subyacente de los servicios de TI más que el resultado final. La figura 13.4 muestra la naturaleza cíclica
del proceso de gestión de servicios que acabamos de comentar.
Subcontratación de sistemas informáticos

La subcontratación se refiere a la transferencia de la prestación de servicios a un tercero, lo que permite a las empresas conc
concentrarse en las competencias básicas. Según el estado de la subcontratación de 2017 de KPMG, los servicios compartido
and Operations Industry Survey Report, TI sigue siendo el mayor usuario de la subcontratación, con
El 94% de las organizaciones utilizan al menos algo de TI tanto para la gestión de aplicaciones como para la infraestructura.
Casi la mitad de las empresas que respondieron han subcontratado sus procesos de TI a terceros.
La subcontratación se utilizó inicialmente para aplicaciones estandarizadas de nómina y contabilidad, o por
empresas para vender su hardware. En un esfuerzo por reducir costos, muchas organizaciones comenzaron a subcontratar
llevar sus funciones de gestión de nómina y recursos humanos (HRM) a las oficinas de servicios de nómina
(PSB) y organizaciones profesionales de empleadores (PEO). Un PSB mantiene los datos maestros de nómina
para cada uno de sus clientes y tramitar su nómina. Además de realizar los servicios PSB
hacer, un PEO también proporciona servicios de gestión de recursos humanos, incluido el diseño y la administración de bene
Cuando las organizaciones subcontratan el procesamiento de nóminas, envían datos de tiempo y asistencia
con información sobre cambios de personal en el PSB o PEO al final de cada período de pago. los
PSB o PEO luego usa esos datos para preparar los cheques de pago de los empleados, los estados de ganancias y una nómina
Registrarse. El servicio de procesamiento de nóminas también produce periódicamente formularios W-2 para empleados y o
informes relacionados con impuestos. Los PSB y PEO representan una opción atractiva para que las empresas reduzcan cost
como:
◾ eliminar la necesidad de preparar cheques de pago para un gran número de empresas;

◾ desarrollar y mantener la experiencia necesaria para cumplir con los cambios constantes
leyes de los Impuestos;
◾ ofrecer una gama más amplia de beneficios a todos sus clientes; y
◾ Liberación de recursos informáticos (p. Ej., Sistema de aplicaciones de gestión de nóminas y beneficios
tems, etc.).
Página 389
Definición
- Identificar servicios
- Alinearse con las necesidades del cliente
- Identificar métricas iniciales
Medición Acuerdo de nivel de servicio

- Definir tipos de SLA
- Identificar qué medir
necesario
- Determinar cómo medir
- Borrador / actualización de SLA
- Seleccionar gestión de servicios
documentos
herramientas
- Identificar la propiedad del SLA
Compromiso y entrega Diseño y precio

- Definir la prestación de servicios - Asignar procesos de TI a servicios
métodos - Definir servicio al cliente
- Servicios de provisión manojos
- Prestar servicios según SLA - Desarrollar modelo de precios
Figura 13.4 Proceso cíclico de gestión de servicios. (Adaptado de Senft, S., Gallegos, F. y
Davis, A. 2012. Control y auditoría de tecnologías de la información . Boca Ratón: CRC Press / Taylor &
Francis.)
La deslocalización es la transferencia de la prestación de servicios a un tercero fuera del país del cliente. Establecido
En el Informe de la encuesta de 2017 de KPMG, la deslocalización se usa con mayor frecuencia en TI y finanzas y
Contabilidad, ambos con un 38%, seguido de atención al cliente con un 24%. Tamaño de la empresa (es decir, organización
zations con ingresos anuales de $ 5 mil millones o más) mostró ser el mayor indicador de offshore
utilizar. Tanto la subcontratación como la deslocalización se han convertido en una práctica empresarial habitual en los distin
industrias durante décadas, como se muestra en los dos ejemplos siguientes.
◾ A finales de los ochenta, The Eastman firmó el primer acuerdo histórico de subcontratación de TI.
Kodak Company (Kodak) e IBM. Kodak contrató a IBM para que se encargara de su procesamiento de datos
operaciones, así como otras empresas para ejecutar funciones de telecomunicaciones y operación de PC
ciones. Los resultados mostraron una disminución significativa en los gastos operativos de las computadoras. Ahorro
relacionados con SI también fueron significativos como resultado del acuerdo de subcontratación.
◾ A mediados de los noventa, Xerox Corporation otorgó un contrato de 10 años y $ 3.2 mil millones a
Electronic Data Systems (EDS) para operar la computadora de Xerox en todo el mundo, el software
red de telecomunicaciones y gestión. Se creía que el acuerdo era el más grande
contrato comercial de este tipo y el primero a nivel mundial.
Página 390
Aunque las organizaciones pueden aumentar la productividad y reducir los costos utilizando recursos internos,
Existen beneficios adicionales al subcontratar o utilizar proveedores extraterritoriales. La subcontratación puede proporciona
Mayor flexibilidad al aprovechar los recursos de un tercero para aumentar o disminuir los recursos.
para una carga de trabajo variable. En algunas organizaciones, es muy difícil reducir la fuerza laboral debido a
legislación o convenios sindicales. La subcontratación permite que una organización transfiera esta responsabilidad
ity a un tercero. Un proveedor global puede transferir recursos a otros compromisos eliminando la
necesidad de reducir la fuerza laboral y proporcionar a las personas mejores oportunidades profesionales.
La deslocalización puede aumentar la productividad si el trabajo o los servicios secuenciales se pueden proporcionar 24
con recursos en diferentes zonas horarias. El soporte de la mesa de ayuda es un buen ejemplo de un servicio que puede
ser subcontratado a un tercero en múltiples zonas horarias para proporcionar a los clientes las 24 horas del día
Servicio.
La subcontratación a un proveedor de servicios maduro puede permitir que una organización aproveche la tecnología
gía y procesos del tercero. Por ejemplo, un gran proveedor de soporte de escritorio ya
tener procesos y tecnología maduros para la implementación, el soporte, la seguridad y la actualización que se pueden
implementado en la organización objetivo.
También existen muchos riesgos con la subcontratación, incluida la dependencia de un tercero, reducción de la flexibilid
flexibilidad (p. ej., sistemas bloqueados, contratos a largo plazo difíciles o costosos de romper, etc.), pérdida de control,
y mayores costos. Las empresas que subcontratan a menudo también pueden experimentar una reducción significativa
ción en ventaja competitiva, moral de los empleados, productividad y niveles de servicio; servicio pobre
y metas incumplidas; falta de realización de ahorros; y gestión de servicios y gobernanza débil
procesos; entre otros.
La subcontratación y la deslocalización pueden requerir cambios significativos en la forma en que las personas trabajan
tendrá que empezar a gestionar los entregables en lugar de las personas. Este cambio puede requerir un paradigma
cambio, así como un cambio de proceso para muchos gerentes. Las organizaciones deben estar preparadas para una
programa de apuntalamiento al tener los procesos establecidos para asegurar el éxito. La gestión de servicios es fundamental
proceso cal a tener en su lugar antes de subcontratar los servicios a un tercero. Las siguientes decisiones
y los procesos deben ser considerados:
◾ Una definición clara del trabajo a subcontratar y realizar offshore.

◾ Cómo se iniciará, transferirá y recibirá el trabajo del tercero.
◾ Eduque al personal sobre cómo trabajar con personas de forma remota, con una cultura diferente, un idioma diferente,
y probablemente una zona horaria diferente.
◾ ¿Hay problemas de privacidad de datos que deban considerarse? En algunos países como Alemania,
algunos datos no se pueden sacar del país ni verlos personas de fuera del país.
Es posible que se necesiten soluciones alternativas para adaptarse a estos requisitos.
Uno de los desafíos que tiene que gestionar el equipo del proyecto de abastecimiento es la pérdida de alcance. Es muy impor
Definir claramente el alcance del trabajo que se subcontratará al proveedor y el trabajo a realizar.
retenido por la organización. Los roles y responsabilidades, procesos y SLA claramente definidos son
también es clave para asegurar un compromiso de subcontratación exitoso. Una organización madura estará en una mejor
puesto para gestionar el trabajo que realiza un subcontratista.
La clave para la planificación inicial es desarrollar una declaración de trabajo para el proyecto de transición que
define los entregables. Los ejemplos de entregables incluyen documentación, el SLA futuro y
personas con conocimiento. Los criterios de aceptación para cada uno de estos son esenciales y deben documentarse
Mentado de antemano. Se debe hacer todo lo posible para que la transición sea de precio fijo o incluso totalmente
a expensas del proveedor, y el equipo no debe pasar al modo subcontratado de estado estacionario hasta que
se pasan los criterios de aceptación acordados.
Página 391
La gobernanza eficaz del proceso ayuda a garantizar que se obtengan los beneficios y que los riesgos
están mitigados. Aunque la prestación de servicios se transfiere, la responsabilidad sigue siendo del cliente
organización. Los SLA y la evaluación comparativa del desempeño existente son absolutamente críticos si la subcontratació
ing debe basarse en el servicio y no solo en el aumento de personal. La intención última es “com-
modificar ”el servicio y estar en condiciones de esperar el servicio contra un nivel acordado y pasar a
otro proveedor con total continuidad de servicio si el servicio no es adecuado.
Participación de la auditoría de TI
Sin la implementación de controles adecuados relacionados con los sistemas de compra o subcontratación /
software, podrían producirse daños innecesarios o interrupciones en la información de la organización. Tal
el daño podría resultar en fallas de los procesos críticos de la organización. Las actividades de control deben ser
implementado para reducir riesgos y abordar objetivos como los anteriores. Las siguientes secciones describen
la participación de la auditoría de TI al auditar tanto adquisiciones de software como organizaciones de servicios.
Auditoría de adquisiciones de software

Una solución de software comprada debe satisfacer de manera eficaz y eficiente los requisitos del usuario. Tambien es
una situación en la que se puede solicitar una auditoría de TI para proporcionar una evaluación externa de los procesos
y procedimientos establecidos y si la adquisición cumplió con los pro-
cesses y procedimientos operativos. TI también puede ser un lugar donde faltan estos procedimientos y
El auditor de TI puede ofrecer ayuda y sugerencias para mejorar.
Los riesgos más comunes asociados con la adquisición de software incluyen la solución seleccionada, no
ser capaz de satisfacer el propósito pretendido, o que no sea técnicamente factible. Las consecuencias
de una mala compra de software son mayores costos, plazos incumplidos o requisitos desatendidos. A
compensar estos riesgos, el Apéndice 9 enumera las áreas de control recomendadas que los auditores de TI deben evaluar cu
adquisiciones de software de auditoría.
Organizaciones de servicios de auditoría

Las organizaciones de servicios (SO) se establecen para ofrecer servicios a las organizaciones que deciden
fuente, por ejemplo, sus servicios de procesamiento de datos. Las entidades que reciben servicios son referidas
como entidades de usuario. Las organizaciones suelen subcontratar el servicio a terceros, como los programas de nómina.
cesing, servicios de computación en la nube, ventas por Internet, servicios de seguridad de la información y servicios de SI.
AICPA AU-C 402 (PCAOB 324) requiere que los auditores de la entidad usuaria (auditores de usuarios) obtengan
una comprensión
importancia de losdeservicios,
cómo la así
organización utilizasobre
como el efecto los servicios
el controldel SO, incluida
interno. la naturaleza
Si los auditores y usuarios no pueden
de los
para obtener una comprensión suficiente de la entidad usuaria, deben obtener esa comprensión
mediante la realización de uno o más de los siguientes procedimientos:
◾ Contactar con el SO, a través de la entidad usuaria, para obtener información específica.
◾ Visite (o contrate a otro auditor para que visite) el SO y realice los procedimientos necesarios sobre
los controles relevantes en el SO
◾ Obtener y considerar el informe de un auditor de servicios (es decir, un auditor que examina e informa
sobre el control interno de los controles de la organización de servicios) sobre los controles de la SO (informes
definido a continuación).
Página 392
Los auditores pueden encontrar que los controles implementados por la entidad usuaria son efectivos para asegurar
que se detecten errores materiales o fraudes en las transacciones. Por ejemplo, el personal de la entidad usuaria
puede generar totales de control de entrada y compararlos con la salida de la SO, sin notar ningún significado
no puedo diferenciar. También pueden volver a realizar cálculos informáticos a modo de prueba. Cuando el
Los resultados de tales controles son efectivos, los auditores necesitan probar solo los controles del cliente (también
como controles basados en el usuario) para obtener la evidencia apropiada; lo que significa que no hay necesidad de realizar
procedimientos de auditoría (por ejemplo, pruebas de controles, etc.) en la organización de servicios. Por otra parte,
si los auditores determinan que los controles implementados en la entidad usuaria pueden no ser efectivos en
asegurando la detección de errores materiales o fraude de transacciones, los auditores pueden contactar al SO y
realizar procedimientos para obtener la comprensión requerida. Además, si el plan de auditoría incluye
una presunción de que ciertos controles operan de manera efectiva, los auditores deben obtener evidencia de
su efectividad operativa independientemente de si esos controles son aplicados por el cliente o
por el SO
La mayoría de las SO tienden a realizar servicios de procesamiento similares para numerosos clientes. Si los auditores
de cada entidad usuaria fueran a visitar el SO, harían preguntas similares y probarían con-
trols. Por lo tanto, es común que el SO contrate su propia firma de auditoría (auditor de servicio) para examinar
o revisar los controles que probablemente sean relevantes para los controles internos de las entidades usuarias sobre
informes. Los auditores de usuarios pueden entonces optar por confiar en los resultados de la auditoría de los auditores de se
(en forma de informe) como alternativa o además de realizar trámites en el SO
sí mismos.
Las declaraciones de la AICPA sobre los estándares para los encargos de atestación (SSAE) 16, sección AT
801 (PCAOB 324), "Informes sobre controles de TI en organizaciones de servicio", aborda el examen
encargos realizados por un auditor de servicios para informar sobre los controles en las organizaciones que proporcionan
servicios a las entidades usuarias cuando es probable que esos controles sean relevantes para el control interno de las entidad
controlar los informes financieros. SSAE 16, sección AT 801, describe las consideraciones de auditoría relacionadas con
entidades que utilizan una organización de servicios y también presenta dos tipos de informes que los auditores de servicio
podría proveer:
◾ Informe Tipo 1 : Informe sobre la descripción de la dirección del sistema de una SO y la idoneidad de
el diseño de controles.
◾ Informe Tipo 2 : Informe sobre la descripción de la dirección del sistema de una SO y la idoneidad de
el diseño y la efectividad operativa de los controles durante el período cubierto por el servicio
informe del vice auditor. Un informe de tipo 2 puede proporcionar al auditor del usuario una base para evaluar
controlar el riesgo por debajo del máximo.
Auditores de usuarios para determinar la suficiencia y adecuación de la evidencia de auditoría proporcionada

por el informe del auditor del servicio, debe considerar la competencia profesional de los auditores del servicio
y su independencia con respecto al SO Cuando la evaluación de riesgos del auditor del usuario y / o
Los requisitos de auditoría incluyen una expectativa de que los controles en el SO operan de manera efectiva, el usuario
Los auditores deben obtener un Informe Tipo 2 (si está disponible) o realizar las pruebas apropiadas de los controles.
para obtener la seguridad de que los controles en la organización de servicios funcionan de manera eficaz. Si la auditora de s
El informe del tor proporciona una base adecuada para la evaluación de los auditores del usuario, por lo general no es necesa
para que los auditores de usuarios realicen sus propias pruebas en el SO
SSAE 18, vigente para las fechas del informe a partir del 1 de mayo de 2017, actualiza SSAE 16 (entre otros
normas de auditoría) aclarando y formalizando los requisitos para realizar e informar sobre la
trabajos de examen, revisión y procedimientos acordados. Los siguientes puntos destacados son relevantes
información sobre el SSAE 18:
Página 393
◾ Proporciona estándares de certificación que establecen requisitos y proporcionan orientación para la aplicación.
a los auditores para realizar e informar sobre el examen, la revisión y el procedimiento acordado
duraderos compromisos, incluidas las atestaciones de Controles de organización de servicios (SOC).
◾ Requiere que la relación entre las organizaciones de servicios y las organizaciones de subservicio sea
divulgado con precisión. Esto significa que las organizaciones de servicios ahora deben identificar todos los subservic
organizaciones utilizadas en la prestación de los servicios, y describen los controles de la organización de subservicio
(si lo hubiera) dependiente de la organización de servicios para proporcionar los principales servicios a los clientes.
◾ Requiere que las organizaciones de servicios proporcionen a los auditores de servicios información de evaluación de ri
con respecto a los principales riesgos internos de la organización.
◾ Requiere que las organizaciones de servicios monitoreen continuamente la efectividad de los controles relevantes
en la organización de subservicio. Los auditores de servicio deben informar sobre la eficacia del procedimiento.
duros utilizados por las organizaciones de servicios para monitorear los controles relevantes en la organización de sub
ción. El seguimiento puede incluir uno o cualquier combinación de los siguientes:
- Revisión y conciliación de informes o archivos de salida
- Discusión periódica con el personal de la organización de subservicio.
- Visitas regulares al sitio
- Controles de prueba en la organización de subservicio
- Monitorización de comunicaciones externas
- Revisión de informes de SOC del sistema de la organización de subservicio
Además de los procesos relacionados con los estados financieros, SSAE 18 informará sobre los
cumplimiento de ciertas leyes o regulaciones, acuerdos contractuales u otro conjunto de
procedimientos acordados.
La sección de SSAE 18 sobre conceptos comunes a todos los encargos de atestación se aplica a los
en los que un CPA en la práctica de la contabilidad pública está contratado para emitir, o emite,
un informe de examen, revisión o procedimientos acordados de un profesional sobre el tema o un
afirmación sobre un tema que es responsabilidad de otra parte. Esta sección contiene
requisitos de desempeño e informes y orientación de aplicación para todos los trabajos de inspección
mentos. Los requisitos y la orientación de esta sección complementan los requisitos y la orientación
en la sección 105, Conceptos comunes a todos los encargos de certificación.
Conclusión
A menudo se piensa que las adquisiciones de software son más rápidas, más fáciles y más económicas para las empresas.
sus necesidades comerciales. Aunque la adquisición de software puede tener mucho éxito, también puede perder
marca. El software comprado puede pasar por alto los requisitos del usuario, superar los objetivos de implementación o impl
costos de instalación, además de introducir retrasos en los cronogramas de negocios o proyectos.
Un proceso de gestión de servicios ayuda a garantizar que se reciban los valores esperados. Para ser eficaz
tiva, la gestión de servicios depende de todas las áreas de TI. La gestión del servicio depende de
procesos que funcionan bien en la gestión de activos, gestión financiera, prestación de servicios, servicio
escritorio, gestión de problemas, gestión de cambios y gestión de relaciones. Adicionalmente,
el cliente tiene la responsabilidad de garantizar la prestación satisfactoria de los servicios de TI mediante
nicando, definiendo requisitos y cumpliendo con los procesos. Es fundamental que el negociado
contratar SLA claramente definidos, medidas de desempeño, términos de precios y procesos de escalamiento para
gestionar eficazmente un proveedor externo. También es importante tener una relación eficaz con
el proveedor y términos de contrato justos que permitan que ambas partes tengan éxito.
Página 394
La subcontratación se refiere a la transferencia de la prestación de servicios a un tercero, lo que permite

nies para concentrarse en las competencias básicas. La subcontratación se utilizó inicialmente para estandarizados
aplicaciones de nómina y contabilidad, o por empresas para vender su hardware. La deslocalización es
la transferencia de la prestación del servicio a un tercero fuera del país del cliente. Ambos subcontratados
El embarque y la deslocalización han sido una práctica común en las diversas industrias durante décadas. ESO
La subcontratación y la deslocalización se han convertido en una práctica comercial común para las organizaciones de
el mundo.
Los auditores de TI pueden proporcionar un servicio importante al participar en el proceso de adquisición para
destacar los riesgos antes de la firma del contrato. Comprender el proceso de adquisición de software,
Los términos críticos del contrato y los procesos de gestión del servicio del proveedor permitirán al auditor
Sea un miembro valioso del equipo de adquisiciones. La auditoría también puede desempeñar un papel importante al
proporcionar una revisión objetiva de los procesos de gestión de servicios. Las expectativas de servicio pueden ser
un área muy polémica para una organización debido a las compensaciones entre la calidad del servicio y
costo. Por último, la auditoría de las organizaciones de servicios permite a los auditores de TI examinar si los controles
implementados por la entidad usuaria son efectivos para asegurar que los errores materiales o el fraude en las transacciones
se detectan ciones.
1. ¿Por qué es importante tener una estrategia implementada? ¿Cuál sería el objetivo de tener tal
¿estrategia?
2. Enumere los siete pasos básicos de un proceso de adquisición de software.
3. Describa los métodos que se pueden utilizar para recopilar información sobre los requisitos del sistema.
4. ¿Cuáles son las ventajas y desventajas del desarrollo contratado o interno?
5. Describa el proceso de selección de proveedores. ¿Cuáles son los componentes básicos de una RFP?
6. Explique qué es un acuerdo de nivel de servicio. Describa brevemente los tipos comunes de nivel de servicio
acuerdos.
7. Al medir los servicios de aplicaciones e infraestructura, una medida importante para ambos es
el número de cambios, ¿por qué?
8. Hay muchas herramientas disponibles para ayudar a las organizaciones a implementar la gestión de servicios.
procesos. Se necesitan herramientas para capturar el rendimiento y las métricas de uso de las diversas plataformas.
formularios y consolidar e informar sobre toda esta información. Describe ejemplos comunes
de las herramientas de gestión de servicios incluyen.
9. Distinga entre subcontratación y deslocalización.
10. Explique los siguientes términos y conceptos relevantes cuando esté involucrado en una auditoría de un servicio.
organización.
a. Organización de servicios.
segundo. Entidad de usuario.
C. Roles y responsabilidades del auditor de usuarios.
re. Funciones y responsabilidades del auditor de servicios.
mi. Propósito de las declaraciones de AICPA sobre estándares para compromisos de atestación
(SSAE) 16, sección AT 801 (PCAOB 324), “Informes sobre los controles de TI en el servicio
Organizaciones ".
F. SSAE 16, sección AT 801, los dos tipos de informes que los auditores de servicios suelen proporcionar.
Página 395
Ejercicios
1. Nombrar y resumir las áreas de control que el auditor de TI debería incluir en su revisión.
al examinar una adquisición de software.
2. Como se indica en el libro de texto, la subcontratación se refiere a la transferencia de la prestación de servicios a un te
partido, lo que permite a las empresas concentrarse en las competencias básicas. Como gerente de auditoría de TI,
su cliente solicita asesoramiento sobre subcontratación, específicamente si debe subcontratar su
principal sistema de contabilidad financiera. Conoce bien los beneficios y los riesgos de la subcontratación
En g. ¿Aconsejaría a su cliente que siga adelante y subcontrate su principal contabilidad financiera?
¿sistema? ¿Si? ¿No? Explique su posición.
3. Con un navegador web de Internet, busque la Declaración de estándares de certificación de AICPA
Compromisos (SSAE) No. 18, y realice lo siguiente:
a. Explique la relevancia de SSAE 18 y sobre qué informa.
segundo. Identificar las ventajas de SSAE 18 para los auditores.
C. Compare SSAE 18 (según corresponda) con SSAE 16.
Respalde sus razones y justificaciones con literatura de auditoría y / o cualquier otra información externa válida.
fuente. Incluya ejemplos según corresponda para evidenciar su caso. Envíe un archivo de Word con
una portada, respuestas a las tareas anteriores y una sección de referencia al final. El enviado
El archivo debe tener entre 5 y 7 páginas (interlineado doble), incluida la portada y
referencias. Esté preparado para presentar su trabajo a la clase.
CASO: ADQUISICIÓN DE SOFTWARE
INSTRUCCIONES: El CFO le pidió a usted, Gerente de Auditoría de TI, que brinde orientación al
Payroll Manager (PM) en la adquisición de software que automatizará el proceso para los empleados
para enviar sus hojas de horas. Las hojas de tiempo son el medio por el cual los empleados por hora envían
su tiempo. Los PM aprueban las hojas de tiempo y luego el departamento de nómina las procesa
personal para el pago. Con el nuevo software, los empleados ingresarán su tiempo semanalmente en
un sistema informático. Una vez que los empleados completen sus hojas de horas, los PM podrán ver
y aprobarlos cuando inicien sesión en el sistema.
TAREA: Utilizando el escenario que se acaba de describir, proporcione respuestas para lo siguiente. Eres fuertemente
Se anima a buscar más allá del capítulo (es decir, literatura de TI y / o cualquier otro
fuente) para respaldar su respuesta. Incluya ejemplos, según corresponda, para evidenciar su caso
punto. Envíe un archivo de Word con una portada, respuestas a la tarea anterior y una referencia.
sección al final. El archivo enviado debe tener entre 6 y 8 páginas (doble línea
espaciado), incluida la portada y las referencias. Esté preparado para presentar su trabajo a la clase.
a. ¿Qué métodos sugeriría al PM para reunir los requisitos para el nuevo

¿sistema?
segundo. ¿Cómo debe el PM abordar y documentar los requisitos del sistema (consulte la
esquema del documento de requisitos proporcionado en el capítulo).
C. ¿Qué dos o tres soluciones alternativas recomendaría que considere el PM?
Página 396
re. Con la ayuda del PM, realice un análisis de viabilidad utilizando las categorías
vido en el captulo y una de las soluciones alternativas descritas en el
pregunta.
mi. Con la ayuda del PM, prepare un análisis de riesgo para el sistema propuesto.
F. ¿A quién recomendaría para formar parte del equipo de pruebas de aceptación?
gramo. ¿Qué pruebas recomendaría para garantizar que los requisitos de rendimiento del sistema
¿se cumplen?
Otras lecturas
1. Ambrose, C. (2006). Un ejecutivo de abastecimiento puede ayudar a optimizar las relaciones de abastecimiento y proveedores ,
Investigación de Gartner, Gartner, Inc., Stamford, CT.
2. AU-C Sección 402. Consideraciones de auditoría relacionadas con una entidad que utiliza una organización de servicios . www
aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AU-C-00402.pdf (consultado
Septiembre de 2017).
3. AU Sección 324. Organizaciones de servicio . https://pcaobus.org/Standards/Auditing/pages/au324.aspx
4. Brown, D. (2013). El enigma del SLA: los ejecutivos ven verde. Pero todos los demás saben que es rojo
dentro. www.kpmg-institutes.com/content/dam/kpmg/sharedservicesoutsourcinginstitute/pdf/2012/
servicio-nivel-acuerdo-conundrum.pdf
5. Bakalov, R. y Nanji, F. (2007). Desarrollo de aplicaciones costa afuera bien hecho. Inf. Syst. Control J. , 5.
6. Benvenuto, N. y Brand, D. (2007). Subcontratación: una perspectiva de gestión de riesgos. Inf. Syst.
Control J. , 5.
7. Comité Ejecutivo Corporativo. Estudios de caso de decisiones de compra de software , Consejo de trabajo para el jefe
Oficiales de información, febrero de 2013.
8. Encuesta de subcontratación global de 2016 de Deloitte. ¡Darse prisa! La subcontratación se dirige directamente hacia la innovac
ción. www2.deloitte.com/us/en/pages/operations/articles/global-outsourcing-survey.html
9. Encuesta Global de Outsourcing e Insourcing de Deloitte 2014. 2014 y más allá. www2.deloitte.
com / content / dam / Deloitte / us / Documents / strategy / us-2014-global-outsourcing-insourcing-
informe de encuesta-123114.pdf
10. Doig, C. 2016. El embudo de adquisición de software empresarial. CIO . www.cio.com/article/3087545/
software / the-enterprise-software-purchase-funnel.html
11. Doig, C. 2016. La recompensa de una rigurosa selección de software. CIO . www.cio.com/article/3091810/
software / the-payoff-from-a-rigorous-software-selection.html
12. Edmead, M. 2015. Uso de COBIT 5 para medir la relación entre negocios y TI. ISACA.
www.isaca.org/COBIT/focus/Pages/using-cobit-5-to-measure-the-relationship-between-business-
and-it.aspx
13. Instituto de Gobernanza de TI. Gobernanza de subcontratación , prácticas de dominio de gobernanza de TI y
Competencias, 2005.
14. Kennedy, C. (25 de julio de 2017). SSAE 18 vs SSAE 16: diferencias clave en el nuevo estándar SOC 1. En línea
Tech. http://resource.onlinetech.com/ssae-18-vs-ssae-16-key-differences-in-the-new-soc-1-standard/
15. Estado de la industria de operaciones, servicios compartidos y outsourcing de KPMG 2017. HfS Research. www.
kpmg-institutes.com/content/dam/kpmg/sharedservicesoutsourcinginstitute/pdf/2017/business-
operaciones-2017-hfs.pdf
16. Kyte, A. (2005). La gestión de proveedores es una disciplina empresarial fundamental , Gartner Research, Gartner, Inc.,
Stamford, CT.
17. Moreno, H. 2016. Cómo la gestión de servicios de TI aporta valor a la empresa digital. Forbes . www.
forbes.com/sites/forbesinsights/2017/03/16/how-it-service-management-delivers-value-to-the-digital-
empresa / # 54ff3bff732e
Página 397
20. Singleton, TW 2013. Cómo auditar adecuadamente a un cliente que utiliza una organización de servicios: informe SOC
o ningún informe SOC. ISACA. www.isaca.org/Journal/archives/2013/Volume-1/Pages/How-to-Properly-
Audite-a-Client-Who-Use-a-Service-Organization-SOC-Report-or-No-SOC-Report.aspx
21. SSAE-18: una actualización de SSAE 16 (disponible en 2017). SSAE-16. www.ssae-16.com/ssae-18-an-update-
to-ssae-16-coming-2017 / (consultado en septiembre de 2017).
22. AICPA. Declaraciones sobre estándares para compromisos de certificación. www.aicpa.org/Research/Standards/
AuditAttest / Pages / SSAE.aspx (consultado en septiembre de 2017).
23. Deloitte. La oficina del programa de gestión de proveedores. Cinco pecados capitales de la gestión de proveedores.
www2.deloitte.com/us/en/pages/operations/articles/vendor-management-program-office-five-deadly-
sins-ofvendor-management.html (consultado en septiembre de 2017).
24. Whittington, OR y Pany, K. (2014). Principios de auditoría y otros servicios de aseguramiento , 20ª edición.
McGraw-Hill / Irwin, Boston.
25. Xerox otorga a EDS un contrato de $ 3,2 mil millones. Archivos UPI. www.upi.com/Archives/1994/06/14/Xerox-
give-EDS-32-billion-contract / 2209771566400 / (consultado en septiembre de 2017).
Página 399
398
Apéndice 1: Memorando de planific
Memorándum
Fecha: [ Fecha ]
A: El archivo de auditoría de estados financieros
Desde: [ Representante del auditor de TI ], [ Ubicación de la oficina ]
Tema: Planificación de auditoría de TI
Propósito
El propósito de este memorando es describir los procedimientos asociados con la participación del
Auditores de tecnología de la información ("Auditores de TI") en relación con el estado financiero
auditoría ("auditoría financiera") de [ nombre de la empresa ] ([" nombre abreviado de la empresa " o "la empresa"])
para el año [ finalizado o finalizado ] [ Mes XX, 20XX ]. El enfoque para la auditoría de TI que se describe en este document
sirve como complemento al memorando de planificación de la auditoría financiera y debe revisarse en
en conjunción con dicho documento de trabajo.
Planificación de discusiones
( La reunión de planificación entre el equipo de auditoría financiera y el equipo de auditoría de TI debe estar documentada
en este memorando de planificación. Modifique las secciones siguientes según corresponda. )
Como se detalla en el documento de trabajo [ número de referencia del documento de trabajo ], una discusión con el
El socio de auditoría, el director o el director se llevaron a cabo para determinar el nivel de participación en la auditoría de T
( Si un auditor de TI ya ha estado involucrado en la auditoría, describa su participación previa y / o cualquier
discusiones de planificación relevantes aquí. ) Durante esta reunión de planificación, las evaluaciones de riesgo de las áreas
también se discutieron junto con la naturaleza, extensión y oportunidad de las pruebas planificadas de
controles descritos más adelante en este memorando de planificación.
373
Página 400
374 ◾ Apéndice 1: Memorando de planificación de TI
Equipo de auditoría de TI
El equipo de auditoría de TI estará compuesto por lo siguiente:
Papel Nombre
Socio, director o director
Gerente o Gerente Senior
Mayor
Personal
Sincronización
El calendario del trabajo de auditoría de TI está programado de la siguiente manera:
1. Planificación (comenzando [ MM / DD / AA ], finalizando [ MM / DD / AA ])

2. Interino (comenzando [ MM / DD / AA ], finalizando [ MM / DD / AA ])
3. Fin de año (comenzando [ MM / DD / AA ], finalizando [ MM / DD / AA ])
4. Fecha de aprobación ([ MM / DD / AA ])
Horas
Las horas y los costos se basan en el tiempo estimado necesario para completar los procedimientos de auditoría de TI y
el nivel de experiencia requerido. Se han planificado procedimientos detallados de auditoría de TI con el
cial de auditoría, incluidas las discusiones sobre la documentación necesaria y la asistencia
proporcionados por la Compañía para facilitar el desempeño eficaz y eficiente de los procedimientos.
Se estima que los procedimientos de auditoría de TI tardarán [ ## ] horas en completarse.
Las horas incurridas se cargarán a: [ Código / número de cargo de la empresa ].
Durante el curso de la auditoría de TI, se encontraron circunstancias que podrían afectar significativamente
La ejecución de dichos procedimientos de auditoría se notificará de inmediato al equipo de auditoría financiera.
y el personal de la Compañía, según corresponda, incluidas las horas adicionales que resulten de dicha
circunstancias.
Comprender el entorno de TI
Se llevarán a cabo reuniones con el personal de la Compañía para recopilar o actualizar los conocimientos
situación del entorno de TI, incluidos los cambios significativos con respecto al año anterior. Esta comprensión
La posición se considerará como parte del proceso de planificación y se documentará en un documento de trabajo.
[ número de referencia del documento de trabajo ].
Aplicaciones y elementos tecnológicos relevantes

Según lo acordado con el equipo de auditoría financiera, las aplicaciones se clasifican como relevantes para la auditoría cuan
ellos:
Página 401
Apéndice 1: Memorando de planificación de TI ◾ 375
◾ se utilizan para respaldar un proceso comercial crítico (por ejemplo, ingresos, gastos, nómina, etc.)
◾ tener información generada por la organización (OIG) que sea significativa para una auditoría financiera
procedimiento de prueba o en el contexto de cualquier control interno, como la información utilizada para probar un
actividad de control relevante o información utilizada por la Compañía para realizar la actividad de control
◾ incluir aplicaciones o actividades de control automatizado que se han identificado como direccionamiento
riesgos importantes de auditoría financiera
Las aplicaciones relevantes y sus elementos tecnológicos relacionados se han identificado en las siguientes
tabla o documentado en [ número de referencia del documento de trabajo ].
Aplicación relevante Base de datos Sistema operativo Red
Controles y riesgos de TI
Los riesgos de TI se han identificado en las aplicaciones relevantes en base a la comprensión obtenida.
de (1) el entorno de TI, (2) los controles de aplicaciones existentes y (3) IGO. Ciertas actividades de control
Se evaluarán las necesidades para determinar si están adecuadamente diseñadas y funcionan con eficacia para
abordar esos riesgos. Consulte el documento de trabajo [ número de referencia del documento de trabajo ] donde dichos con
han sido identificados y listados.
Controles de aplicaciones relevantes

Además de las áreas generales de control de TI (operaciones de sistemas de información, seguridad de la información,
y gestión de control de cambios), el equipo de auditoría de TI probará ciertos controles de aplicación relevantes.
Las reuniones entre el equipo de auditoría de TI y los miembros apropiados del equipo de auditoría financiera
ocurrir a:
1. comprender cómo funcionan las aplicaciones o los controles automatizados

2. evaluar si se han diseñado e implementado adecuadamente
3. evaluar si operan de manera efectiva
Los controles de aplicación relevantes que se van a probar se indican a continuación.
Hoja de trabajo
Referencia # Aplicación relevante Control de aplicaciones relevantes
Página 402
376 ◾ Apéndice 1: Memorando de planificación de TI
Información generada por la organización

IGO ha sido identificada y clasificada como significativa para un procedimiento de prueba de auditoría o en el contexto de
cualquier control interno. Esto significa que cierta información se utilizará como parte de varias pruebas de auditoría.
de los controles y / o el personal de la organización los utilizará para realizar los controles. Dada la relevancia
de esta información, la auditoría de TI incluirá procedimientos para evaluar su precisión e integridad.
Evaluación de deficiencias
Si las desviaciones o hallazgos resultan de los procedimientos de prueba de TI realizados, se evaluarán para
determinar su naturaleza y causa, y si representan una deficiencia de control. Evaluación de
Las deficiencias de control se realizarán en conjunto con el equipo de auditoría financiera. Consulte el trabajo
documento de trabajo [ número de referencia del documento de trabajo ], donde se documentará dicha evaluación.
Trabajo de otros
( El trabajo de otros puede incluir trabajo de auditores internos, personal de la Compañía (además de
auditores nacionales), y terceros. El lenguaje de muestra a continuación se centra en la auditoría interna y debe
adaptado si se utiliza el trabajo de otros. )
El equipo de auditoría de TI planea confiar en la función de Auditoría Interna (IA) de la Compañía para respaldar
los procedimientos de control de TI. ( Este lenguaje debe modificarse si IA se utilizará en una "asistencia directa"
capacidad versus usar el propio trabajo de IA. )
Si se confiará en ciertas áreas de auditoría realizadas por el personal de AI, el equipo de auditoría de TI
Evaluar y documentar la competencia y objetividad de dicho personal de AI cuyo trabajo será
en el que se confía para determinar hasta qué punto se puede utilizar dicho trabajo.
Para determinar la calidad y efectividad del trabajo específico realizado por los auditores internos, el
Se evaluará lo siguiente:
◾ si el trabajo de AI es apropiado para cumplir con los objetivos de auditoría

◾ si el programa de trabajo de auditoría de AI es adecuado y completo
◾ si la documentación de trabajo de AI es aceptable en calidad y cantidad
◾ si los resultados y las conclusiones son apropiados y consistentes con el trabajo de EI
Evaluación de los controles de la organización de servicios

( Esta sección es aplicable si hay organizaciones de servicios externos que prestan servicios o servicios generales
controles relevantes para la auditoría. )
Se obtendrá un informe del auditor del servicio para los controles generales relevantes relacionados con el [ relevante
aplicación (es) ] aplicación (es) realizada por [ nombre de la organización de servicios ]. Una revisión del informe
será realizado por el equipo de auditoría de TI para comprender los servicios relevantes proporcionados por el servicio
organización. Específicamente, el equipo de auditoría de TI evaluará los controles de la organización de servicios mediante:
◾ evaluar los controles de TI y las excepciones relacionadas en el informe
Página 403
Apéndice 1: Memorando de planificación de TI ◾ 377
◾ documentar los controles de usuario complementarios o locales de TI especificados en el informe

( Estos controles se implementan en la Compañía y, por lo tanto, no son parte de la organización de servicios
ción; sin embargo, complementan los controles de la organización de servicios. El auditor de TI generalmente docum
estos controles vinculándolos al trabajo de auditoría de TI realizado como parte de la auditoría de TI de
controla las áreas de TI. )
( La siguiente tabla se puede incluir para resumir la información sobre las organizaciones de servicios relevantes ) .
Breve
Descripción de
Pertinente Servicio
Servicio Servicios) Organización Servicio Reporte Tipo de informe/
Organización Previsto Ubicación Auditor Período Conclusión
Otras áreas de asistencia de auditoría de TI

( Esta sección incluye otras áreas donde los auditores de TI pueden brindar asistencia al equipo de auditoría financiera,
incluyendo, pero no limitado a, asistencia contra fraudes, pruebas de controles comerciales / financieros, pruebas de nivel d
controles, etc. )
Página 405
404
Apéndice 2: Comprensión
el entorno de TI
[ Nombre de la empresa ]
Comprensión del entorno de tecnología de la información de la organización
[ Periodo bajo auditoría ]
El nombre del entorno de tecnología de la información (TI) es también el nombre del entorno operativo subyacente.
sistema (s) que alojan las aplicaciones financieras pertinentes.
Entorno de TI
Riesgos
TI plantea riesgos específicos para el control interno de una organización, que incluyen, por ejemplo, no autorizados
divulgación de datos confidenciales; procesamiento no autorizado de información; manual inapropiado
intervención; fallos del sistema; modificación no autorizada de información sensible; robo o daño
al hardware; y pérdida / robo de información, entre otros.
Control S
Hay dos grandes grupos de controles de TI, los cuales son esenciales para abordar los riesgos y para
Asegurar el funcionamiento continuo y adecuado de los sistemas de información. Estos son los siguientes:
◾ Controles informáticos generales o Controles generales . Incluyen políticas y procedimientos que se relacionan
a las aplicaciones y respaldar el funcionamiento eficaz de los controles de aplicaciones. Contrato general
Los controles cubren la infraestructura de TI y los servicios de soporte, incluidos todos los sistemas y aplicaciones.
Los controles generales comúnmente comprenden controles sobre áreas de TI como (1) sistemas de información
operaciones, (2) seguridad de la información y (3) gestión de control de cambios.
◾ Controles de aplicación . Estos también pueden denominarse "controles automatizados" y se aplican a
controles de procesamiento específicos y exclusivos de las aplicaciones. Los controles de la aplicación están relacion
con la exactitud, integridad, vigencia y autorización de los datos capturados, ingresados,
procesado, almacenado, transmitido y reportado.
379
Página 406
380 ◾ Apéndice 2: Comprensión del entorno de TI
Aplicaciones relevantes
Documente las aplicaciones relevantes asociadas con el entorno de TI. Aplicaciones para ser
incluidos en esta tabla son aquellos que impactan la generación de información financiera (es decir,
declaraciones).
Fuente de la aplicación Base de datos

(p. ej., interno Servidor
Solicitud desarrollado, comprado Nombre/
Nombre del servidor/ software, alojado Relacionado Operando
Solicitud Operando por un servicio Base de datos Sistema
Nombre (s) Versión del sistema organización, etc.) Nombre (s) Versión Ubicación
Modificaciones significativas a las aplicaciones

Describa las modificaciones significativas para las aplicaciones relevantes enumeradas anteriormente, si las hubiera, durante
período objeto de auditoría.
Nombre de la aplicación Descripción y fecha de modificación signi cativa
Organizaciones de servicio
Documentar la información sobre las organizaciones de servicios relacionadas con el entorno de TI.
Nombre y Breve descripción de relevantes Aplicación relevante relacionada a la que

Ubicación Servicios prestados Los servicios se realizan para
Organización y personal
Documentar si el enfoque de la organización hacia los sistemas de información y las actividades de apoyo relacionadas
los lazos están centralizados o descentralizados.
¿Centralizado o descentralizado? Explique
Documente el número del personal dentro del departamento de TI y los nombres y cargos del personal clave.
Incluya una copia del organigrama de TI, si está disponible.
Número de personal dentro del departamento de TI
Nombres y títulos del personal clave de TI
Página 407
Apéndice 2: Comprensión del entorno de TI ◾ 381
Controles informáticos generales

Operaciones de sistemas de información
El área de operaciones de sistemas de información incluye actividades de control como copias de seguridad de datos y
almacenamiento, programación de trabajos, supervisión de trabajos y seguimiento de excepciones y acceso físico.
Copias de seguridad
1. Describa el proceso de copia de seguridad existente para

proteger la información relevante de la aplicación.
2. Documente los nombres de las herramientas de respaldo utilizadas.
3. Describa la frecuencia y el (los) tipo (s) de

copia de seguridad (s) realizada.
4. ¿Cuál es la frecuencia de rotación de las copias de seguridad para
instalaciones fuera del sitio? Describe brevemente el fuera del sitio
instalaciones.
Herramienta de programación de trabajos automatizada
1. ¿Se utiliza una herramienta automatizada para ejecutar

trabajos programados regularmente relacionados con
aplicaciones, bases de datos y operaciones
sistemas, como interfaces programadas de
datos, purgas de datos, actualizaciones de tablas, etc.?
2. Nombre la herramienta de programación de trabajos automatizada

utilizado y describir los tipos de trabajos
programado.
3. ¿Cómo se realizan los cambios en el trabajo automatizado?
herramienta de programación, como agregar, modificar,
y eliminar trabajos y horarios realizados?
4. Quién puede realizar cambios en el trabajo automatizado

herramienta de programación, como agregar, modificar,
y eliminar trabajos y horarios?
Procesamiento de trabajos
1. Describa el proceso utilizado para monitorear

finalización exitosa del procesamiento del trabajo.
2. Documentar cómo dicho seguimiento y revisión
proceso asegura que las excepciones y / o
Las fallas identificadas durante el procesamiento del trabajo son
resuelto oportunamente.
3. Nombrar al personal responsable de la
revisión de procesos y seguimiento de excepciones
mencionado anteriormente.
4. Nombre los informes que se revisan y el
sistemas y mecanismos de notificación establecidos.
Página 408
Seguridad física
1. ¿Qué métodos (p. Ej., Tarjetas de acceso,

biometría, cerradura y llave tradicionales,
guardias de seguridad, etc.)
organización emplean para restringir físicos
acceso a este entorno de TI, incluido
el centro de datos o la sala de ordenadores, como
así como otras áreas informáticas donde
los intrusos podrían acceder a la información
recursos? Si la autenticación biométrica
está empleado, especifique si
la autenticación es mediante huella dactilar,
venas de la palma, reconocimiento facial, iris
reconocimiento, escaneos de retina, voz
verificación, etc.
2. Qué usuarios tienen acceso a los datos
¿centrar?
3. Describa las políticas y procedimientos en

lugar para otorgar acceso a los datos
centrar. Son solicitudes y aprobaciones
requerido y completado antes de tal
se concede el acceso?
4. Para un empleado que deja el

organización o se transfiere a una
departamento diferente, describa el
proceso implementado para cambiar su
acceso al centro de datos. Considerar
(1) nombrar al personal involucrado;
(2) ¿cómo se les notifica para eliminar tales
acceso al centro de datos; y (3) como
el acceso oportuno se cambia para reflejar el
nuevo estado del empleado.
5. ¿Se realizan revisiones de acceso de usuarios a

apoyar el acceso físico actual concedido
a este entorno de TI, incluido el
centro de datos que aloja información financiera
aplicaciones, bases de datos relacionadas,
sistemas operativos y otros
repositorios de información financiera? Si
entonces, describa el proceso y la frecuencia.
El área de seguridad de la información incluye actividades de control tales como políticas y procedimientos de concientizac
duros; solicitudes de acceso y administración de cuentas de usuario; terminaciones de acceso; revisiones de acceso de usua
administración de seguridad del sistema, aplicaciones y bases de datos (es decir, parámetros de contraseña); y fisico
seguridad.
Página 409
Políticas y procedimientos de seguridad de la información
1. ¿Los usuarios conocen las políticas de seguridad de la información?

y procedimientos establecidos en la organización? Si es así,
¿cómo?
2. ¿Las políticas de seguridad de la información y
procedimientos formalmente escritos? Si es así, enumere los nombres
de las políticas, procedimientos,
y prácticas, o agregue una referencia donde puedan ser
encontró.
Administración de acceso
1. Para cada aplicación enumerada bajo Relevante

En la sección de aplicaciones , documente lo siguiente:
a. Nombre del personal responsable de autorizar
y modificar el acceso de los usuarios a la información.
segundo. Método de autorización para agregar y modificar
acceso a la cuenta de usuario. Se realiza
electrónicamente, a través de un formulario manual con firma,
verbalmente, etc.?
2. Describe el proceso de agregar y modificar usuarios.
acceso a la cuenta para la base de datos, sistema operativo,
e infraestructura de red relacionada con los
aplicaciones.
3. ¿Es el proceso de agregar y modificar usuarios
acceso a la cuenta dentro de las aplicaciones relevantes,
bases de datos, sistemas operativos y redes
diferente para contratistas y empleados temporales?
¿Si es así, cómo?
4. Cuando los empleados dejan la organización o son

transferidos dentro de la organización:
a. ¿Quién notifica a los administradores de sistemas de TI? Esta ahí
un mecanismo de notificación automatizado implementado
(por ejemplo, flujo de trabajo, etc.) o dependencia de Human
Personal de recursos o el gerente del empleado
para contactar a las partes apropiadas?
segundo. ¿Cuál es el plazo requerido para la notificación?
(por ejemplo, inmediatamente, diariamente, semanalmente, mensualmente, etc.)?
C. ¿Cuál es el método de comunicación con TI?
administradores del sistema (por ejemplo, por correo electrónico, teléfono
llamada, formularios manuales, etc.)?
5. ¿Están cubiertos los contratistas y empleados temporales?
bajo el procedimiento de terminación descrito anteriormente?
Si no es así, describa los procedimientos actualmente en vigor.
6. ¿Se define explícitamente la propiedad de los datos? Si es así,

Explique cómo.
Página 410
Reseñas de acceso de usuario
1. ¿Se realizan revisiones de acceso de usuarios para

todas las aplicaciones relevantes, relacionadas
bases de datos y sistemas operativos, así
como otros repositorios de finanzas
¿información? Si es así, describe el proceso
y frecuencia.
Técnicas y parámetros de autenticación
1. ¿Cómo se autentican u obtienen los usuarios?

acceso a aplicaciones financieras relevantes?
¿Es a través de varias capas (es decir, iniciar sesión
primero a la red, luego a la
sistema operativo, y finalmente al
aplicación), o es a través del inicio de sesión único?
Describir.
2. Para cada aplicación relevante, base de datos relacionada, sistema operativo y red, especifique el
siguientes parámetros de autenticación reforzados por el sistema:
Pertinente Hacer cumplir Mínimo Mínimo Contraseña Cuenta Otro

Solicitud/ Contraseña Contraseña Contraseña Complejidad Bloqueo
Operando Historia Edad (cambiar Longitud (habilitado / (especificar
Sistema/ (número de intervalo (número de discapacitado) número
Base de datos/ contraseñas cada 30, caracteres) de inválido
Red (también recordado) 60, 90 días, iniciar sesión
incluir la etc.) intentos)
Privado virtual
Red (VPN),
si es aplicable)
Nota: Normalmente, una política de contraseñas implementada en todos los sistemas y aplicaciones incluye
los siguientes parámetros mínimos recomendados de autenticación de seguridad lógica:
• Hacer cumplir el historial de contraseñas de seis contraseñas recordadas o más.

• Antigüedad mínima de la contraseña (o intervalo de vencimiento) entre 30 y 90 días.
• Longitud mínima de la contraseña de seis caracteres o más.
• La complejidad de la contraseña debe habilitarse en la medida de lo posible para todos los sistemas y
aplicaciones.
• Bloqueo de cuenta entre tres y cinco intentos de inicio de sesión no válidos antes de que se bloqueen las cuentas.
Página 411
Acceso a la información
1. ¿La organización permite

acceso ao desde sus sistemas informáticos
(a través de redes externas)? Si es así, documente:
a. Quién tiene tal acceso y cuál es el
propósito de dicho acceso?
segundo. ¿Cuáles son los métodos utilizados para
restringir tal acceso?
2. ¿La organización transmite
información a través de redes externas
como Internet?
3. ¿Se cifran los datos sensibles o críticos?
mientras se transmite? ¿Si es así, cómo?
4. ¿Pueden las aplicaciones financieras u otras
la información relacionada con las finanzas
se accede desde ubicaciones remotas?
5. Describa los métodos utilizados para proteger

aplicaciones financieras de la organización
de acceso no autorizado desde remoto
ubicaciones. Si se utiliza una VPN, describa
requisitos de autenticación.
6. ¿La organización utiliza un firewall? Si

por lo tanto, documente lo siguiente:
a. Nombre del firewall y su ubicación.
segundo. ¿Qué es la función de cortafuegos (una
manera, bidireccional o proxy)?
C. ¿Cómo se configura, utiliza,
y gestionado?
7. ¿Se puede acceder a las aplicaciones financieras?
de forma inalámbrica? Si es así, describe los métodos
utilizado para asegurar tal inalámbrico
conexión.
8. ¿Cuál es el nombre de la organización?
Sitio web de Internet? Si aplica, especifique
si el sitio permite a los usuarios colocar
pedidos o pagar bienes o servicios, y
donde está alojado (por ejemplo, localmente, por un
proveedor de servicios de terceros, etc.)
Gestión de control de cambios

El área de gestión del control de cambios incluye actividades de control relacionadas con los cambios implementados en
aplicaciones relevantes, incluida la aprobación de solicitudes, priorización, auditoría y revisión; implementación de
actualizaciones y parches para sistemas operativos; implementación de aplicaciones y bases de datos, incluida la instalació
lación de actualizaciones; y supervisión, seguridad y gestión de cambios para la infraestructura de red.
Página 412
Aplicaciones
Aplicaciones compradas
1. Describe el proceso de selección y compra.

nuevas aplicaciones. Considere los roles y
responsabilidades de las personas involucradas en la
proceso.
2. ¿Cómo se personalizan las aplicaciones compradas?
3. ¿Cómo se aplican las nuevas aplicaciones o los nuevos lanzamientos

aplicaciones probadas y aprobadas antes de
implementación desde desarrollo / prueba
entornos en el entorno de producción?
4. Después de la implementación, ¿cómo se
validado por su integridad, precisión e integridad
propósitos.
Programa y aplicaciones desarrolladas internamente

Cambios
1. Describa el proceso de la organización para desarrollar

aplicaciones internas, incluidos los sistemas
metodologías de desarrollo utilizadas y los roles
y responsabilidades de las personas involucradas.
2. Describa el proceso de la organización para
implementar cambios en el programa a nivel interno
aplicaciones desarrolladas. Considera lo siguiente:
a. ¿Cómo se prueban los cambios del programa?
segundo. Después de la prueba, ¿cómo se modifican los programas?
aprobado para su implementación en el
¿entorno de producción?
C. ¿Cómo es la implementación en la producción?
entorno realizado? Quien mueve el
¿Cambiar al entorno de producción?
re. Después de la implementación, ¿cómo se
validado por su integridad, precisión y
propósitos de integridad.
3. ¿Los programadores tienen acceso para modificar el código o
datos de producción directamente en la producción
entorno para las aplicaciones relevantes? Explique.
4. ¿Tienen los programadores acceso para migrar sus propios
cambios de entornos de prueba o desarrollo
en el entorno de producción? Si es así, ¿por qué?
5. Describe el proceso para mantener el control de versiones.

y para evitar que se realicen cambios no autorizados
implementado en el entorno de producción.
Página 413
Bases de datos
1. Describa el proceso de adquisición,

implementar y mantener bases de datos.
Considere los roles y responsabilidades de
personas involucradas en este proceso.
2. Documentar la arquitectura de la base de datos para

aplicaciones relevantes (por ejemplo, base de datos integrada
utilizado por todas las aplicaciones relevantes, múltiples
bases de datos independientes, etc.)?
3. Nombre el software de administración de la base de datos (por ejemplo,

Oracle, IBM DB2, propietario, etc.) utilizado por
cada aplicación relevante.
4. ¿La organización mantiene datos
diccionarios con definiciones y
representaciones de los elementos de datos almacenados en
las bases de datos? Describe cómo los datos
se utilizan diccionarios.
Las definiciones y representaciones de los datos pueden
incluir restricciones de integridad, procedimientos almacenados,
estructura general de la base de datos, asignaciones de espacio,
etc.
Redes
1. Enumere las aplicaciones relevantes admitidas por

red. Incluir copia del diagrama de red
o un diagrama gráfico de la red.
2. Describa el proceso de implementación
cambios de configuración, actualizaciones y / o nuevos
software de red, incluida su aprobación y
pruebas.
Sistemas operativos
1. Describa el proceso para adquirir, implementar y

mantenimiento de sistemas operativos. Considere los roles y
responsabilidades de las personas involucradas en este proceso.
2. ¿Cómo evalúa la organización el impacto de
implementar nuevos (o modificar los existentes) operativos
sistemas para albergar las aplicaciones relevantes?
3. ¿Cómo se implementan los nuevos sistemas operativos o las modificaciones?
sistemas operativos existentes probados y aprobados antes de
migración a entornos de producción?
4. Después de la implementación, ¿cómo se obtiene la información?

validado por su integridad, precisión e integridad
propósitos.
Página 414
Los controles de aplicación también se pueden denominar "controles automatizados" y se aplican al procesamiento
controles específicos y únicos para las aplicaciones. Los controles de la aplicación se refieren a la precisión,
integridad, validez y autorización de los datos capturados, ingresados, procesados, almacenados, transferidos
mitted y reportado. Describa los controles de aplicación implementados actualmente en la organización.
ción. Los controles de la aplicación pueden incluir, entre otros:
◾ Controles de configuración del sistema y / o aplicaciones

◾ Controles relacionados con la seguridad que imponen el acceso de los usuarios, los roles y la segregación de funciones
◾ Controles de notificación automatizados para alertar a los usuarios que una transacción o proceso está esperando su
acción
◾ Cálculos matemáticos automatizados para evitar errores
◾ La validación de entrada comprueba la precisión de los datos
Otra información
Comercio electrónico / Tecnologías emergentes
1. Describe cómo la organización usa

comercio electrónico.
2. Tener tecnologías emergentes como la nube
informática, etc. implementado en el
¿organización? Si es así, describa cómo. Si no,
¿Tiene la organización planes para
implementar tecnologías emergentes en el
¿futuro cercano?
Información generada por la organización

1. ¿Utiliza la organización el redactor de informes?
software para crear informes personalizados desde
datos relevantes de la aplicación? Si es así, nombre el
software de redacción de informes.
Se pueden generar informes personalizados
utilizando herramientas de consulta de base de datos, o capturando
datos de un almacén de datos .
2. Describa el propósito del uso del informe.
software de escritura anterior y nombre a los usuarios
con acceso a dicho software de redacción de informes.
3. ¿Hay cambios en los informes personalizados en
cumplimiento del control de cambios
proceso de gestión documentado en
¿esta forma? Si no es así, describa el proceso actual.
Página 415
Planes futuros
1. ¿La organización planea actualizar o

reemplazar las aplicaciones relevantes existentes,
bases de datos, red y / u operación
sistemas en un futuro próximo? Si es así, describe
tales planes.
Trabajo de TI anterior
1. ¿Ha habido algún trabajo relacionado con TI?

realizado recientemente por consultores,
auditores internos / externos, etc.que pueden
cambiar significativamente la comprensión
documentado dentro de este formulario? Si es así,
describir el trabajo realizado (p. ej., naturaleza
y alcance del trabajo, período cubierto,
resultados obtenidos, etc.).
Página 417
416
Apéndice 3: Muestra
Programas de auditoría de TI para
Áreas de TI de control general
Programa de auditoría de TI para operaciones de sistemas de información

Procesamiento por lotes y en línea, copias de seguridad y acceso físico
Objetivo de control de auditoría
ISO 1.00 - Las operaciones de TI respaldan la programación, ejecución, monitoreo y continuidad adecuados
de sistemas, programas y procesos para garantizar el procesamiento completo, preciso y válido y
Actividades de control de auditoría

ISO 1.01 - El procesamiento por lotes y / o en línea se define, se ejecuta oportunamente y se monitorea para su éxito.
finalización completa.
ISO 1.02 - Las excepciones identificadas en el procesamiento por lotes y / o en línea se revisan y corrigen oportunamente.
rected para asegurar un procesamiento preciso, completo y autorizado de la información financiera.
ISO 2.00 - El almacenamiento de información financiera se gestiona de forma adecuada, es precisa y completa.

ISO 2.01 - Procedimientos para la restauración y recuperación de información financiera a partir de copias de seguridad
se han implementado en caso de que se produzcan interrupciones en el procesamiento, procedimientos de apagado y reinicio
ISO 2.02: se han implementado herramientas de respaldo automatizadas para administrar planes de retención de datos y
horarios.
ISO 2.03: las copias de seguridad están debidamente etiquetadas, almacenadas en una ubicación externa segura para el medi
y rotado a dicha instalación de forma periódica.
391
Página 418
392 ◾ Apéndice 3: Ejemplos de programas de auditoría de TI
ISO 2.04: las pruebas de legibilidad de las copias de seguridad se realizan periódicamente. Soporte de resultados
restauración oportuna y exitosa de los datos respaldados.

ISO 3.00 - El acceso físico se gestiona adecuadamente para salvaguardar los componentes relevantes de la TI.
infraestructura e integridad de la información financiera.

ISO 3.01 - Se utiliza un mecanismo de control de acceso físico para restringir y registrar el acceso al edificio.
ing y a la sala de computadoras (es decir, centro de datos), y la autoridad para cambiar dicho mecanismo es
ISO 3.02 - El acceso físico está autorizado, monitoreado y restringido a las personas que lo requieran.
acceso para realizar sus funciones laborales. La entrada de personal no autorizado se supervisa y registra. los
El registro es mantenido y revisado regularmente por la gerencia de TI.
Programa de auditoría de TI para la seguridad de la información

Función de administración de seguridad, políticas de seguridad y
Procedimientos, herramientas y técnicas de software de seguridad, únicos
Identificadores de usuario y contraseñas, administrador de seguridad
y Privilege Access, y registros de seguridad de la información
ISEC 1.00 - Configuración de seguridad de aplicaciones, bases de datos, redes y sistemas operativos
se gestiona adecuadamente para proteger contra cambios no autorizados en programas y datos que pueden
resultar en un procesamiento o registro incompleto, inexacto o inválido de información financiera.

ISEC 1.01: la función de administración de seguridad debe estar separada de la función de TI.
ISEC 1.02 - Las políticas y procedimientos formales definen los objetivos de seguridad de la información de la organización
tivas y las responsabilidades de los empleados con respecto a la protección y divulgación de información
recursos macionales. La gerencia monitorea el cumplimiento de las políticas y procedimientos de seguridad, y
el acuerdo con estos se evidencia mediante la firma de los empleados.
ISEC 1.03 - Existen herramientas y técnicas de software relacionadas con la seguridad para restringir y segregar
acceso a funciones de TI sensibles (por ejemplo, programación, funciones administrativas, implementación
de cambios en los entornos de producción, etc.) dentro de los sistemas. Los cambios relacionados con el acceso son
evaluado por la dirección para la adecuada separación de funciones.
ISEC 1.04 - La implementación y configuración de herramientas y técnicas de software de seguridad son

revisado y aprobado por la gerencia.
ISEC 1.05 - Se han asignado identificadores de usuario únicos a los usuarios según se requiera en la información
políticas y procedimientos de seguridad, para distinguirlos y hacer cumplir la responsabilidad.
Página 419
Apéndice 3: Ejemplos de programas de auditoría de TI ◾ 393
ISEC 1.06 - Consistente con las políticas y procedimientos de seguridad de la información, usuarios locales y remotos
son necesarios para autenticarse en aplicaciones, bases de datos, redes y sistemas operativos a través de
palabras para mejorar la seguridad informática.
ISEC 1.07: las contraseñas deben promover niveles aceptables de seguridad (coherentes con las políticas y / o
mejores prácticas de la industria) al hacer cumplir la confidencialidad y un formato de contraseña seguro.
ISEC 1.08: contraseñas proporcionadas por el proveedor integradas en las aplicaciones, bases de datos, redes y
Los sistemas operativos se modifican, eliminan o desactivan para evitar vulnerabilidades de seguridad de
siendo explotado en los sistemas.
ISEC 1.09: el acceso a la cuenta de administrador, privilegiado o superusuario dentro de los sistemas está limitado
ited al personal apropiado. Los cambios en estas cuentas (p. Ej., Parámetros de seguridad del sistema,
roles, configuración de seguridad de los sistemas, etc.) son registrados y revisados por la gerencia.
ISEC 1.10 - Los registros de seguridad de la información se configuran y activan en aplicaciones, bases de datos,
redes y sistemas operativos para registrar e informar eventos de seguridad consistentes con la información
ISEC 1.11: informes generados a partir de registros de seguridad de la información (por ejemplo, informes de violaciones de
intentos no autorizados de acceder a información, etc.) se revisan con frecuencia y se toman medidas
necesario.

ISEC 2.00 - Se implementa una seguridad adecuada para proteger contra el acceso no autorizado y la modificación.
caciones de sistemas e información, que pueden resultar en el procesamiento o registro de datos incompletos,
información financiera inexacta o no válida.

ISEC 2.01 - Se han establecido programas de formación para todo el personal dentro de las siguientes áreas:
◾ Políticas de seguridad organizacional
◾ Divulgación de datos sensibles
◾ Privilegios de acceso a los recursos de TI
◾ Notificación de incidentes de seguridad
◾ Convenciones de nomenclatura para contraseñas de usuario
ISEC 2.02: los propietarios del sistema autorizan las cuentas de usuario y la naturaleza y extensión de su acceso
privilegios.
ISEC 2.03: los sistemas y la aplicación revisan periódicamente los privilegios de acceso a la cuenta de usuario
propietarios para determinar si son razonables y / o siguen siendo apropiados.
ISEC 2.04 - Usuarios que han cambiado roles o tareas dentro de la organización, o que han sido
transferidos o cancelados son informados inmediatamente al departamento de seguridad para la cuenta de usuario
acceder a la revisión para reflejar el estado nuevo y / o revisado.
ISEC 2.05: la transmisión de información confidencial está cifrada de acuerdo con las políticas de seguridad
y procedimientos para proteger su confidencialidad.
Página 420
394 ◾ Apéndice 3: Ejemplos de programas de auditoría de TI
Programa de auditoría de TI para la gestión del control de cambios

Evaluación de riesgos, documentación, solicitud de cambio
Autorización, prueba, aprobación de cambios en el sistema y
Implementación en el entorno de producción
CCM 1.00: cambios implementados en aplicaciones, bases de datos, redes y sistemas operativos
(en conjunto denominados "cambios del sistema") se evalúan por riesgo, se autorizan y se documentan minuciosamente
mento para asegurar que los resultados deseados sean los adecuados.

CCM 1.01: la gerencia evalúa los riesgos comerciales y el impacto de los cambios propuestos en el sistema
antes de la implementación en entornos de producción. Los resultados de la evaluación se utilizan cuando el diseño
dotación de personal y programación de la implementación de cambios para minimizar las interrupciones en las operaciones
CCM 1.02 - Las solicitudes de cambios en el sistema (por ejemplo, actualizaciones, arreglos, cambios de emergencia, etc.) s
mento y aprobado por la gerencia antes de que se realice cualquier trabajo relacionado con el cambio.
CCM 1.03 - La documentación relacionada con la implementación del cambio es adecuada y completa.
CCM 1.04: la documentación de cambios incluye la fecha y hora en que se realizaron (o se realizarán
estar instalado.
CCM 1.05 - La documentación relacionada con la implementación del cambio se ha publicado y

comunicado a los usuarios del sistema.

CCM 2.00 - Cambios implementados en aplicaciones, bases de datos, redes y sistemas operativos
(a los que se hace referencia en conjunto como "cambios del sistema") se prueban adecuadamente. Las pruebas las realiza un
grupo distinto del grupo responsable del sistema (por ejemplo, se implementan cambios en el sistema operativo)
mentado por alguien que no sea el programador de sistemas, etc.).
CCM 2.01: los cambios del sistema se prueban antes de la implementación en el entorno de producción
coherente con los planes y casos de prueba.
CCM 2.02 - Planes de prueba y casos que involucran datos de prueba completos y representativos (en lugar de
datos de producción) están aprobados por los propietarios de la aplicación y la dirección de desarrollo.
CCM 2.03 - Se selecciona una muestra de cambios del sistema para el período bajo auditoría para determinar
si la documentación que respalda el cambio:
1. cumple con las normas de instalación;

2. proporciona una explicación clara del cambio realizado y el motivo del cambio; y
3. ha sido debidamente revisado y aprobado por la dirección.
CCM 2.04 - Se selecciona una muestra de cambios del sistema para el período bajo auditoría para determinar
si los planes de prueba y los casos:
Página 421
Apéndice 3: Ejemplos de programas de auditoría de TI ◾ 395
1. cumplen con los estándares de instalación;

2. probado a fondo el cambio implementado;
3. fueron revisados y aprobados adecuadamente; y
4. se probaron en un entorno de protección separado del entorno de producción.
CCM 2.05 - Los nombres y títulos del personal responsable de implementar cambios en el sistema son
identificado. El acceso a los entornos de desarrollo o de prueba es independiente y está debidamente restringido
al entorno vivo o de producción (es decir, separación adecuada de funciones).

(en conjunto, "cambios del sistema") se gestionan de forma adecuada para reducir las interrupciones,
alteraciones no autorizadas y errores que afectan la precisión, integridad y proceso válido
ing y registro de información financiera.
Actividad de control de auditoría

CCM 3.01: se identifican los problemas y errores encontrados durante la prueba de cambios del sistema,
corregido, vuelto a probar, seguido para su corrección y documentado.

(en conjunto, "cambios del sistema") están aprobados formalmente para respaldar la precisión, la completa,
y procesamiento y registro válido de información financiera.

CCM 4.01: antes de la implementación de cambios de sistema en entornos de producción y en vivo,
Se obtiene documentación de aceptación formal que respalde que las pruebas se han realizado satisfactoriamente.
completado, los resultados de la prueba fueron exitosos y adecuados para evitar la manipulación y los requisitos del usuario
se encontraron.
CCM 4.02 - Personal independiente de aquellos con acceso al entorno de desarrollo o prueba
Los comentarios revisan los cambios y los implementan en el entorno de producción o en vivo.
CCM 4.03: procedimientos tales como conservar una versión anterior del entorno original están en su lugar
para permitir la recuperación de dicho entorno original en caso de que haya problemas derivados de
la implementación de cambios en el sistema.
CCM 4.04: la administración realiza una revisión general después de que se hayan realizado los cambios en el sistema.
implementado en el entorno vivo o de producción para determinar si los objetivos para la implementación
Se cumplieron los cambios en el sistema menting.
Nota: A continuación se muestran ejemplos de plantillas de programas de auditoría de TI . No olvide documentar en la part
programa de auditoría el nombre de la organización y el período objeto de auditoría .
Página 422
Área de TI: OPERACIONES DE SISTEMAS DE INFORMACIÓN
Temas tratados: procesamiento por lotes y en línea, copias de seguridad y acceso físico
Descripción de los procedimien

Realizado o referencia al traba
Papel (s) donde se han realizado lo
Objetivo de control Actividad de control Documentado
ISO 1.00 - Soporte de operaciones de TI ISO 1.01 - Lote y / o en línea

adecuada programación, ejecución, el procesamiento está definido, oportuno
seguimiento y continuidad de ejecutado y monitoreado para
sistemas, programas y procesos completar con exito.
para asegurar la completa, precisa,
y procesamiento válido y
ISO 1.02 - Excepciones identificadas en

procesamiento por lotes y / o en línea son
revisado y corregido oportunamente para
Asegurarse de que sea precisa, completa y
procesamiento autorizado de finanzas
información.
ISO 2.00 - El almacenamiento de información financiera

ISO 2.01 - Procedimientos para la
la información es apropiada restauración y recuperación de
administrado, preciso y completo. información financiera de copias de seguridad
se han implementado en el
caso de interrupción del procesamiento,
procedimientos de apagado y reinicio
coherente con las políticas de TI y
procedimientos.
ISO 2.02: herramientas de copia de seguridad automatizadas

se han implementado para gestionar
planes y horarios de retención de datos.
Página 423
Área de TI: OPERACIONES DE SISTEMAS DE INFORMACIÓN
Temas tratados: procesamiento por lotes y en línea, copias de seguridad y acceso físico
Descripción de los procedimien

Realizado o referencia al traba
Papel (s) donde se han realizado lo
Objetivo de control Actividad de control Documentado
ISO 2.03: las copias de seguridad están correctamente
etiquetado, almacenado en un lugar seguro fuera del sitio
ubicación ambiental, y rotado
a dicha instalación de forma periódica.
ISO 2.04 - Pruebas para la legibilidad de
las copias de seguridad se realizan en un
base periódica. Soporte de resultados
restauración oportuna y exitosa de
datos respaldados.
ISO 3.00 - El acceso físico es ISO 3.01 - Un control de acceso físico

adecuadamente gestionado para mecanismo se utiliza para restringir y
salvaguardar los componentes relevantes de registrar el acceso al edificio y a
la infraestructura de TI y la la sala de ordenadores (es decir, datos
integridad de la información financiera. centro), y autoridad para cambiar
tal mecanismo se limita a
personal apropiado.
ISO 3.02 - El acceso físico es

autorizado, supervisado y
restringido a personas que
requieren tal acceso para realizar
sus deberes laborales. Entrada de
personal no autorizado es
supervisado y registrado. El registro es
mantenido y revisado periódicamente
por la gestión de TI.
Página 424
Área de TI: SEGURIDAD DE LA INFORMACIÓN
Temas cubiertos: función de administración de seguridad, políticas y procedimientos de seguridad, herramientas y técnicas de software de s
Identificadores y contraseñas, administrador de seguridad y acceso privilegiado, y registros de seguridad de la inf
Descripción de los procedimientos de a

Realizado o referencia al trabajo
Papel (s) donde se han establecido los p
Objetivo de control Actividad de control Ha sido documentado
ISEC 1.00 - Configuración de seguridad ISEC 1.01 - La seguridad

de aplicaciones, bases de datos, la función de administración debe
redes y sistemas operativos estar separado de la función de TI.
se gestiona adecuadamente para proteger
contra cambios no autorizados a
programas y datos que pueden
resultar en incompletos, inexactos,
o procesamiento no válido o
registro de finanzas
información.
ISEC 1.02 - Políticas formales y

los procedimientos definen el
información de la organización
objetivos de seguridad y
responsabilidades de los empleados
con respecto a la protección
y divulgación de información
recursos. administración
supervisa el cumplimiento de
políticas y procedimientos de seguridad,
y acuerdo con estos son
evidenciado por la firma de
empleados.
Página 425
Descripción de los procedimientos de

Papel (s) donde se han establecido los
ISEC 1.03: relacionado con la seguridad

herramientas y técnicas de software
están en su lugar para restringir y
segregar el acceso a TI sensible
funciones (por ejemplo, programación,
funciones administrativas,
implementación de cambios en
entornos de producción, etc.)
dentro de los sistemas. Cambios
relacionados con el acceso son evaluados por
manejo adecuado
segregación de deberes.
ISEC 1.04 - Implementación y

configuración de seguridad
herramientas y técnicas de software
son revisados y aprobados por
administración.
ISEC 1.05: identificadores únicos de usuario

han sido asignados a usuarios como
requerido en la información
políticas y procedimientos de seguridad,
para distinguirlos y para
hacer cumplir la responsabilidad.
Página 426

ISEC 1.06 - Consistente con

políticas de seguridad de la información y
procedimientos, locales y remotos
los usuarios deben
autenticarse en aplicaciones,
bases de datos, redes y
sistemas operativos mediante contraseñas
para mejorar la seguridad informática.
ISEC 1.07: las contraseñas deben

promover niveles aceptables de
seguridad (consistente con las políticas
y / o mejores prácticas de la industria)
haciendo cumplir la confidencialidad y
un formato de contraseña seguro.
ISEC 1.08: suministrado por el proveedor

contraseñas incrustadas en el
aplicaciones, bases de datos,
redes y sistemas operativos
se modifican, eliminan o
inhabilitado para evitar la seguridad
vulnerabilidades de ser
explotado en los sistemas.
Página 427
ISEC 1.09 - Administrador,

cuenta privilegiada o de superusuario
el acceso dentro de los sistemas son
Cambios en estas cuentas (p. Ej.,
parámetros de seguridad del sistema,
roles de seguridad, seguridad
configuración sobre sistemas, etc.)
son registrados y revisados por
administración.
ISEC 1.10 - Seguridad de la información

los registros están configurados y activados
en aplicaciones, bases de datos,
redes y sistemas operativos
para registrar y reportar seguridad
eventos consistentes con la información
ISEC 1.11 - Informes generados

de los registros de seguridad de la información
(por ejemplo, informes de violaciones de seguridad,
Intentos de acceso no autorizados
información, etc.) son frecuentemente
revisado y actuado como
necesario.
Página 428

ISEC 2.00 - La seguridad adecuada es ISEC 2.01 - Los programas de formación tienen
implementado para proteger contra establecido para todo el personal
acceso no autorizado y dentro de las siguientes áreas:
modificaciones de sistemas y
• Seguridad organizacional
información, que puede resultar en
politicas
el procesamiento o grabación de
• Divulgación de datos sensibles
incompleto, inexacto o inválido
• Acceso a privilegios de TI
información financiera.
recursos
• Informes de seguridad
incidentes
• Convenciones de nomenclatura para el usuario
contraseñas
ISEC 2.02: propietarios del sistema
autorizar cuentas de usuario y
naturaleza y alcance de su acceso
privilegios.
ISEC 2.03 - Acceso a la cuenta de usuario

los privilegios son periódicamente
revisado por sistemas y
propietarios de aplicaciones para determinar
si son razonables
y / o seguir siendo apropiado.
Página 429
Descripción de los procedimientos de

Papel (s) donde se han establecido los
ISEC 2.04 - Usuarios que tienen

cambio de roles o tareas dentro del
organización, o que han sido
transferidos o cancelados son
informado inmediatamente a la
departamento de seguridad para el usuario
revisión de acceso a la cuenta en orden
para reflejar el nuevo y / o revisado
estado.
ISEC 2.05 - Transmisión de

la información sensible es
cifrado de acuerdo con
políticas y procedimientos de seguridad
para proteger su confidencialidad.
Página 430
Área de TI: GESTIÓN DE CONTROL DE CAMBIOS
Temas cubiertos: evaluación de riesgos, documentación, autorización de solicitud de cambio, pruebas, aprobación de cambios del sistema e im
en el entorno de producción
Descripción de los procedimi
Realizado o referencia al trab
Papel (s) donde se han estable
Objetivo de control Actividad de control Ha sido documentad
CCM 1.00 - Cambios implementados en CCM 1.01 - Los riesgos comerciales y la

aplicaciones, bases de datos, redes, impacto de los cambios propuestos en el sistema
y sistemas operativos (en total son evaluados por la gerencia antes
denominados "cambios del sistema") son implementación en producción
evaluado por riesgo, autorizado y Ambientes. Resultados de la evaluación
documentado a fondo para asegurar se utilizan al diseñar, dotar de personal,
los resultados deseados son adecuados. y programación de la implementación de
cambios para minimizar las interrupciones en
operaciones.
CCM 1.02 - Solicitudes de sistema

cambios (por ejemplo, actualizaciones, correcciones,
cambios de emergencia, etc.) son
documentado y aprobado por
gestión antes de cualquier cambio-
se realiza el trabajo relacionado.
CCM 1.03 - Documentación relacionada

a la implementación del cambio es
adecuado y completo.
CCM 1.04 - Cambiar documentación

incluye la fecha y hora en que
Los cambios fueron (o serán) instalados.
CCM 1.05 - Documentación relacionada
a la implementación del cambio ha
ha sido entregado a los usuarios del sistema.
Página 431

CCM 2.00 - Cambios implementados en CCM 2.01 - Los cambios del sistema son
aplicaciones, bases de datos, redes, probado antes de la implementación en
y sistemas operativos (en total el entorno de producción
denominados "cambios del sistema") coherente con los planes y casos de prueba.
se prueban adecuadamente. Las pruebas son
realizado por un grupo que no sea
el grupo responsable de la
sistema (por ejemplo, sistemas operativos
los cambios son implementados por
alguien que no sean los sistemas
programador, etc.).
CCM 2.02 - Planes de prueba y casos

involucrando completo y
datos de prueba representativos (en lugar de
datos de producción) son aprobados por
propietarios de aplicaciones y
gestión del desarrollo.
Página 432

CCM 2.03: una muestra de cambios del sistema

se selecciona para el período objeto de auditoría
para determinar si la documentación
apoyando el cambio:
1. está de acuerdo con la instalación

estándares;
2. proporciona una explicación clara de
el cambio realizado y el motivo
por el cambio; y
3. ha sido debidamente revisado
y aprobado por la gerencia.
CCM 2.04 - Una muestra de sistema

se selecciona cambios para el período
bajo auditoría para determinar si
planes de prueba y casos:
1. cumplen con
estándares de instalación;
2. probado a fondo el
cambio implementado;
3. fueron revisados y debidamente
aprobado; y
4. fueron probados en un protector
ambiente separado del
Página 433

CCM 2.05 - Los nombres y títulos de

personal responsable de
implementar cambios en el sistema son
identificado. Acceso al
entornos de desarrollo o prueba
está separado y apropiadamente
restringido a la producción en vivo o
medio ambiente (es decir, adecuado
separación de tareas).
CCM 3.00 - Cambios implementados en CCM 3.01 - Problemas y errores

aplicaciones, bases de datos, redes, encontrado durante la prueba de
y sistemas operativos (en total se identifican los cambios del sistema,
denominados "cambios del sistema") corregido, vuelto a probar, seguido por
se gestionan adecuadamente para corrección y documentada.
reducir las interrupciones, no autorizado
alteraciones y errores que
impactar la precisión, integridad,
y procesamiento y registro válidos
de información financiera.
Página 434

CCM 4.00 - Cambios implementados en CCM 4.01 - Antes de la implementación
aplicaciones, bases de datos, redes, de cambios en el sistema en vivo y
y sistemas operativos (en total entornos de producción,
denominados "cambios del sistema") documentación de aceptación formal
están formalmente aprobados para apoyar se obtiene respaldando esa prueba
exacto, completo y válido se ha completado satisfactoriamente,
procesamiento y grabación de los resultados de la prueba fueron exitosos y
información financiera. adecuado para evitar la manipulación, y
se cumplieron los requisitos del usuario.
CCM 4.02 - Independiente del personal

de aquellos con acceso a la
entornos de desarrollo o prueba
revisar los cambios e implementarlos en
el entorno vivo o de producción.
CCM 4.03 - Procedimientos como

conservando una versión anterior del
entorno original están en su lugar para
Permitir la recuperación de tal original
medio ambiente en el caso de que haya
problemas resultantes de la
implementación de cambios en el sistema.
Página 435

CCM 4.04 - Una revisión general es

realizado por la gerencia después
Se han realizado cambios en el sistema
implementado en vivo o
entorno de producción para
determinar si los objetivos
para implementar cambios en el sistema
se encontraron.
Página 437
436
Apéndice 4: Mejores prácticas de A

Procedimientos de prueba
Asientos de diario de contabilidad
Los procedimientos de auditoría señalados en este apéndice crean resultados que pueden justificar inversiones adicionales.
tigación. Realizar más procedimientos de desglose (p. Ej., Clasificar por monto en dólares, filtrar por
número de cuenta, estratificar por fecha, clasificar por usuario, etc.) según el interés específico de auditoría y
aún puede ser necesario el juicio. Esto sería necesario para identificar los asientos del diario contable.
exhibiendo características de interés para ser seleccionados para pruebas detalladas.
La documentación típica del papel de trabajo cuando se prueban entradas de diario incluye detalles de la
entradas de diario seleccionadas, resultados de la elaboración de perfiles y otros análisis, y descripciones del procedimiento
duras realizadas. Los siguientes son pasos comunes que siguen los auditores al probar la contabilidad
entradas de diario con ACL:
◾ Conciliar y formatear datos para pruebas basadas en ACL

◾ Analizar la población de entradas de diario
◾ Identificar indicadores potenciales de controles débiles sobre el proceso de publicación de asientos de diario.
Reconciliación y formato de datos para pruebas basadas en ACL

Los auditores deben conciliar el resumen de los asientos del diario proporcionado por la entidad (es decir, la organización
o cliente de auditoría) al balance de prueba relevante (T / B) bajo auditoría por la cuenta del libro mayor (G / L).
Esto se hace con el fin de determinar si los asientos de diario obtenidos representan el
población. Habrá situaciones en las que no se logre la conciliación de datos. Cuando este es el
caso, la entidad debe proporcionar un nuevo resumen de los asientos del diario, o se le pedirá que concilie
entre las entradas de diario descargadas y el T / B. El equipo de auditoría deberá realizar
procedimientos para asegurar la exactitud de la conciliación de la entidad.
Una vez reconciliados, los siguientes procedimientos ayudarán a los auditores a formatear y preparar
datos de entrada de diario para análisis y pruebas basados en ACL:
A. Verificación de saldo para confirmar que todos los débitos y créditos en todo el archivo de asientos de diario se reduc
Confirme que todos los asientos de diario individuales se reduzcan a cero . Las líneas de detalle de las entradas de dia
nents de una sola entrada de diario mayor. Todas las líneas de detalle de una entrada de diario, cuando se resumen,
debe tener débitos iguales a créditos.
411
Página 438
412 ◾ Apéndice 4: Procedimientos de mejores prácticas de ACL
B. Conciliar los datos de asientos de diario con los estados financieros sobre los que se están aplicando los procedimien
realizado. Concilie el archivo de datos de entrada de diario recibido con los estados financieros (por ejemplo,
T / B, etc.) sobre los que se están realizando procedimientos de auditoría para evaluar la integridad de los
archivo de datos de entrada de diario utilizado para las pruebas. El archivo de detalles de la entrada de diario debe ten
campos, número de cuenta, descripción de la cuenta, saldo inicial, así como débitos y créditos.
C. Separe los asientos de diario estándar y no estándar. Archivos de entrada de diario, una vez conciliados
el T / B, debe segregarse entre estándar (automatizado) y no estándar (manual)
entradas de diario, si es posible.
D. Excluir ciertos grupos de asientos de diario de un análisis adicional basado en la comprensión del auditor.
la posición del proceso de información financiera de la entidad y el juicio con respecto al riesgo de material
inexactitud debida a fraude.
Análisis de la población de entradas de diario

El auditor debe analizar la población de asientos de diario para generar estadísticas resumidas.
tics de tal población. Esta información es útil para comprender la composición
ción de toda la población de entradas de diario. Antes de realizar los análisis, puede resultar útil
ejecutar procedimientos de alto nivel para obtener una descripción general del tamaño y la composición general de la revista
líneas de detalle dentro del archivo de entrada de diario.
Identi cación de posibles indicadores de debilidad

Controles sobre el proceso de contabilización de asientos de diario
Los auditores examinan los datos de las entradas del diario para identificar posibles desviaciones en los
eficacia de los controles internos sobre el cierre financiero y el proceso de presentación de informes, y los
controles informáticos generales. Luego, los auditores marcan las entradas del diario de interés para probarlas
selección o inclusión de subpoblaciones en el proceso de selección de muestras.
Al identificar posibles indicadores de debilidades en los controles sobre la publicación de asientos de diario
proceso, los auditores deben evaluar dichos indicadores para determinar si representan deficiencias
en las actividades de control relacionadas. Los auditores también deben documentar su consideración del efecto de
tales deficiencias.
Los indicadores potenciales a continuación se utilizan comúnmente para identificar desviaciones en el asiento del diario
datos. Esta lista no es exhaustiva, ya que se pueden usar (y probar) indicadores adicionales basados en
para el juicio y los factores de riesgo de la entidad. Después de probar cada indicador, el auditor evalúa los resultados
para determinar el volumen, el tamaño y el tiempo de las selecciones que se realizarán con el fin de obtener
fuerte sobre la validez de las entradas del diario.
Indicador potencial de
Controles débiles Descripción de los procedimientos realizados
A. Cuentas transitorias Todas las cuentas transitorias deben estar identificadas y ser significativas.
cuentas transitorias o elementos revisados por la gerencia.
Valide que los saldos de la cuenta transitoria netos a cero como
esperado.
(Continuado)
Página 439
Apéndice 4: Procedimientos de mejores prácticas de ACL ◾ 413
B. Autorización de usuario Resuma las publicaciones de los usuarios durante el período de prueba para identificar:
1. Usuarios no autorizados, o aquellos usuarios que no se espera que

publicar entradas de diario.
2. Actividad de usuario incoherente o inesperada: si un usuario
terminado, no debe haber publicaciones de ese usuario
después de la fecha de terminación.
3. Usuarios que pueden haber superado su autorización de publicación
nivel.
4. Usuarios con totales altos y bajos de recuento.
Deben diseñarse procedimientos para identificar la revista
entradas realizadas por personas que normalmente no hacen
entradas como característica de interés a considerar. UN
se toma una decisión sobre lo que constituye "infrecuente"
basado en el juicio profesional del equipo auditor
y su comprensión de los procesos comerciales de la entidad.
5. Entradas de diario con ID de usuario en blanco o faltantes.
Nota: ACL es capaz de contar el número de

líneas de entrada de diario que cada usuario ingresó durante el período
en revisión para identificar a los usuarios poco frecuentes.
C. Detalle de líneas con inválido Buscar características relevantes de asientos de diario para
Plan de cuentas (COA) indicadores de posibles debilidades en cuenta
información mantenimiento.
Identificar las líneas de detalle de las entradas del diario que representan la actividad
cuentas que no figuran en el COA. Si un gran porcentaje de
las cuentas en el COA no se utilizan en los
proceso de presentación de informes, puede ser un indicador de que el COA está
no se mantiene con regularidad.
D. Líneas de detalle duplicadas Identificar líneas de detalle de asientos de diario duplicadas y duplicar
Publicaciones en la misma cuenta. Por ejemplo, líneas de detalle
que tienen el mismo número de entrada de diario y línea
número representa una entrada duplicada potencial.
E. Detalle de líneas con Identificar entradas en el archivo de entradas de diario que no

fecha de vigencia fuera del relacionados con la actividad en el período objeto de examen.
período de prueba
F. Detalle de líneas con un inválido Identifique las entradas que tienen una fecha posterior que no
posfechar tienen sentido lógico (por ejemplo, una entrada que tiene lugar lejos en el
pasado o futuro, etc.).
G. Parte relacionada e inusual Busque transacciones con partes relacionadas en el Libro mayor.
actas La gerencia debe aprobar todas las transacciones con partes relacionadas
y / o transacciones y eventos inusuales, incluidos aquellos
que exceden los límites establecidos. Se requiere la aprobación de la junta
para tipos específicos de partes relacionadas y / o inusuales
transacciones, y esta aprobación debe ser
documentado.
(Continuado)
Página 440
414 ◾ Apéndice 4: Procedimientos de mejores prácticas de ACL
H. Cuentas de uso poco frecuente Revise las cuentas con pocas líneas registradas en un
período. La determinación de "pocos" se basa en
juicio y entendimiento de las finanzas de la entidad
proceso de presentación de informes. Cuente el número de veces que cada cuenta
se utilizó en las entradas durante el período objeto de examen.
I. Detalle de entrada de diario grande Identificar la línea de detalle de entrada de diario más grande para un
líneas por cuenta cuenta.
J. Entradas con palabras clave de Escanee el campo de descripción de la entrada del diario e identifique las entradas
interés de auditoría en con palabras clave de interés de auditoría. A continuación se muestran algunas palabras clave
descripciones que podría ser buscado. No todas estas palabras clave son
aplicable a todas las situaciones, y puede haber otras palabras para
considere buscar que no estén incluidos en este listado.
adj, ajustar, alterar, según lo solicitado, capital,

cfo, clasif, confidencial, controlador, correcto, tarro de galletas,
borrar, cubrir, encubrimiento, ebit, ebit,
oculto, ebitda, error, fraude, ficticio, esconder,
inmaterial, inadecuado, inapropiado, aumento, gatito, administrar
ganancias, manip, declaración incorrecta, oportunidad, enchufe, recl, reclasificar, recls,
reconciliar, reducir, reducir, reafirmar, rev, revertir, revertir, riesgos,
pantalla, secreto, suave, propagación, temp, prueba, transf, tsfr, txfr
K. Entradas con créditos para Identificar asientos de diario con al menos un crédito a los ingresos
ingresos cuentas. La prueba proporciona información sobre el débito de compensación
para considerar si el débito no está relacionado con el
crédito (por ejemplo, Débito: Activo fijo y Crédito: Ingresos, etc.).
L. Entradas con créditos a Identificar asientos de diario con al menos un crédito a gastos
gastos cuentas.
M. Entradas realizadas en inusuales Identifique las entradas reservadas en días inusuales. Estos podrían ser
dias días de fin de semana o festivos, dependiendo de lo que sea
considerada práctica inusual en la entidad.
N. Días con publicación Revise los días dentro del período bajo revisión para
frecuencia exterior patrones para identificar entradas de diario para un análisis más detallado. Esta
rango esperado El procedimiento identifica los días durante el período objeto de examen.
con pocas o muchas contabilizaciones de asientos de diario.
O. Entradas publicadas cerca del final Identificar las entradas del diario que se publicaron en el
del período objeto de examen sistema contable cerca del final del período bajo
o como entradas posteriores al cierre revisión, que tienen poca o ninguna descripción.
que tienen poco o nada
explicación o descripción
P. Detalle de líneas con espacio en blanco Todas las líneas de detalle de una entrada suelen tener una descripción. Esta
descripción de la entrada del diario El procedimiento identifica entradas sin suficiente
descripción.
(Continuado)
Página 441
Apéndice 4: Procedimientos de mejores prácticas de ACL ◾ 415
P. Diferencias entre publicación Examine el lapso de tiempo entre la publicación y las fechas de vigencia para
y fechas de vigencia identificar entradas de diario para un análisis más detallado.
R. Cantidades específicas en dólares Identificar entradas con montos específicos en dólares, miles,
millones, etc. para un análisis más detallado.
S. Dólar de uso frecuente Identificar las cantidades que se utilizan con más frecuencia que otras
cantidades cantidades.
Ley de T. Benford Identificar asientos de diario con montos inusuales basados en

Análisis de la ley de Benford. Marque las entradas del diario que
mayor riesgo de posible selección e investigación futuras.
Ley de Benford, también llamada ley de los primeros dígitos (se puede aplicar
en varios dígitos iniciales), establece que en listas de números
de muchas fuentes de datos de la vida real, los dos dígitos iniciales
ocurren mucho más a menudo que los otros (es decir, aproximadamente
30% del tiempo). Además, cuanto mayor sea el dígito, el
es menos probable que ocurra como los dos dígitos iniciales de un
número. Esto se aplica a figuras relacionadas con el mundo natural.
o de importancia social; ya sean números tomados de
facturas de electricidad, artículos de periódicos, direcciones de calles, existencias
precios, números de población o constantes matemáticas.
Esta prueba intenta identificar cantidades que están sesgadas
debido a un intento de eludir una restricción antinatural
(por ejemplo, un control que limita el tamaño de una entrada debido a una
autoridad de firma del empleado, etc.).
U. Entradas con recurrente Identificar las entradas donde la cantidad tiene un final recurrente
dígitos finales, incluidos dígitos.
cantidades redondas en dólares
V. Gestión de estimaciones Analizar las tendencias en los saldos de las cuentas que involucran a la administración.
estimaciones para identificar sesgos potenciales (una forma de gestión
anulación de controles). Identificar las entradas realizadas cerca del final
del período a cuentas que tienen saldos relacionados con
estimaciones de gestión (por ejemplo, provisiones y acumulaciones,
etc.).
Si alguno de los procedimientos antes mencionados impulsa un análisis e investigación adicionales, los auditores
debe utilizar el juicio para determinar si el archivo recibido de la entidad está completo, y que
contiene información válida. Si existe alguna preocupación con los resultados, una discusión con los
El personal de la entidad debe tener lugar para determinar si partes del archivo de datos de entrada de diario
deben eliminarse (lo que también puede ayudar a conciliar con el T / B), si los resultados identificados
representan cuestiones que deben tenerse en cuenta y / o si se va a solicitar un nuevo archivo de asientos.
Página 443
442
Apéndice 5: Riesgo de TI
Ejemplo de evaluación
Uso de NIST SP 800-30
La evaluación de riesgos utilizada en este ejemplo se basa en el Instituto Nacional de Estándares y

Guía de tecnología (NIST) SP 800-30, "Guía para realizar evaluaciones de riesgos". * La guía es
de conformidad con las políticas presentadas en la Circular A-130 de la Oficina de Gestión y Presupuesto,
Apéndice III, “Seguridad de los recursos de información automatizados federales”; la seguridad informática
Ley de 1987; y la Ley de reforma de la seguridad de la información del gobierno de octubre de 2000. NIST SP
La evaluación de riesgos de 800-30 incluye los siguientes nueve pasos:
1. Caracterización del sistema

2. Identificación de amenazas
3. Identificación de vulnerabilidades
4. Análisis de control
5. Determinación de probabilidad
6. Análisis de impacto
7. Determinación del nivel de riesgo
8. Recomendaciones de control
9. Documentación de resultados
Los pasos anteriores se implementan para identificar los riesgos de seguridad de la información asociados con los
sistema de información de la organización. El Paso 1 al Paso 7 (excepto el Paso 4) se relaciona directamente con el riesgo
evaluación. Los pasos 4, 8 y 9 se relacionan con la identificación e implementación de controles que mitigan
puerta o reducir riesgos, así como documentación de resultados. A continuación se muestra un ejemplo que muestra cómo
La evaluación de riesgos del NIST se implementa en una organización.
Paso 1. Caracterización del sistema
NIST enfatiza en obtener una comprensión profunda del sistema de TI, así como en establecer
Conocer el alcance de la evaluación de riesgos y las limitaciones del sistema de TI que se evalúa.
La comprensión recopilada debe incluir información detallada para permitir la identificación de
riesgos potenciales.
417
Página 444
418 ◾ Apéndice 5: Evaluación de riesgos de TI
Descripción general de la organización, el departamento de TI y el alcance

La Universidad XYZ ("la Universidad") está situada en la costa sur de Florida (FL). La Universidad
ofrece títulos de asociado, bachillerato, maestría y / o doctorado en artes, humanidades, ciencias naturales y
ciencias sociales, así como en áreas profesionales como negocios, educación, enfermería, derecho y medicina.
tecnología cal. Actualmente, hay aproximadamente 15.000 estudiantes que asisten a la Universidad.
En lo que respecta a las TI y las actividades de apoyo relacionadas, el enfoque de la Universidad está centralizado. Es de
El procesamiento informático de la Universidad lo realiza el departamento de TI, que es el único proveedor
de tecnología y telecomunicaciones para los departamentos de la Universidad. Además, el departamento de TI
proporciona procesamiento de datos y soporte al usuario final para los sistemas y aplicaciones de la Universidad,
incluida la formación y documentación de los controles y procedimientos del sistema de aplicación. El departamento de TI
La estructura organizativa del ment se compone de 30 empleados, bajo la dirección de un Director Ejecutivo de TI.
El alcance de esta evaluación de riesgos es el sistema de solicitud financiera de la Universidad. La aplicación
El cation se llama Banner Finance ("Banner") y se ejecuta en un sistema operativo Red Hat Enterprise Linux.
sistema. Consulte el Anexo A5.1.
Recopilación de información relevante para la evaluación de riesgos

Durante el proceso de evaluación de riesgos, la información relevante se recopila a través de revisiones e inspecciones.
de documentación, así como entrevistas in situ con personal clave de gestión. Gestión de claves
El personal para los propósitos de este ejemplo incluye:
◾ Director Ejecutivo de TI (ITED)

◾ Administrador de seguridad de banner (BSA)
◾ Supervisor de operaciones (SO)
◾ Administrador de sistemas (SA)
◾ Administrador de red (NA)
Al entrevistar al ITED y a la BSA, se observó que Banner tiene críticas y

información sobre finanzas, contabilidad, recursos humanos (RR.HH.) y nómina. La BSA más
agregó que los usuarios de Banner incluyen personal de finanzas, contabilidad, recursos humanos y soporte técnico / de TI.
Basado en la revisión de la documentación, la Universidad tiene varias políticas y procedimientos establecidos
relacionados con las operaciones de los sistemas de información, la seguridad de la información y la gestión del control de c
En cuanto a la infraestructura de red, la NA indicó que la Universidad brinda una amplia
variedad de recursos de redes para todos los miembros calificados dentro de la comunidad universitaria. Acceso
a computadoras, sistemas y redes es un privilegio que impone ciertas responsabilidades y obligaciones
ciones, y que se otorga sujeto a las políticas de la universidad, así como a las leyes locales, estatales y federales. Todas
los usuarios deben cumplir con las políticas y pautas, y actuar de manera responsable mientras usan los recursos de la red.
Acceso físico a las instalaciones de la Universidad y su centro de datos, según el ITED y
el sistema operativo, está restringido a través de mecanismos de seguridad, que incluyen (1) dispositivos biométricos, (2) seg
Anexo A5.1 Sistema de aplicación financiera en el ámbito de la evaluación de riesgos
Nombre / funcionamiento del servidor de aplicaciones

Nombre de la aplicación Versión del sistema Ubicación del servidor de aplicaciones
Bandera INB.xyzfl.edu/Red Hat Enterprise Linux Centro de Computación,

Sede de la Universidad, FL
Página 445
Apéndice 5: Evaluación de riesgos de TI ◾ 419
guardias, (3) videovigilancia y (4) registros de visitantes. La autoridad para cambiar el físico anterior
Los mecanismos de control de acceso se limitan al ITED. El SO también declaró que la Universidad ha
Implementó varios controles ambientales con el fin de evitar daños a los equipos informáticos,
y para proteger la disponibilidad, integridad y confidencialidad de los datos. Son los siguientes: extinción de incendios
equipo (es decir, FM-200 y extintores de incendios), fuentes de alimentación ininterrumpida, energía alternativa
generadores y pisos elevados.
Cuando se les preguntó acerca de la seguridad lógica de la información en torno a Banner, tanto la SA como la BSA estu
en lo siguiente:
◾ Se han configurado algunos ajustes de contraseña aunque la configuración actual no es coherente

tienda con las mejores prácticas de la industria.
◾ Se realizan revisiones del acceso de los usuarios dentro de Banner, pero no de forma periódica. Terminado
Las cuentas de usuario se eliminan de Banner, pero no de manera oportuna. Soporte de documentación
No se mantienen las revisiones de portabilidad ni la eliminación del acceso de los usuarios.
◾ Los programadores están restringidos a realizar cambios y modificaciones (es decir, actualizaciones y mejoras)
a Banner en un entorno de prueba / desarrollo antes de su implementación en producción.
Sin embargo, los resultados de las pruebas no son revisados por la gerencia (es decir, ITED) ni aprobados antes
Implementación en producción.
Por último, se realiza una copia de seguridad de la información del banner a diario, aunque el sistema operativo declaró que
almacenados localmente ya que la Universidad no tiene instalaciones externas para el almacenamiento de respaldo.
Paso 2. Identi cación de amenazas

NIST define una amenaza como "cualquier circunstancia o evento con el potencial de impactar adversamente
operaciones y activos organizacionales, individuos, otras organizaciones o la Nación a través de un
sistema de información a través del acceso no autorizado, destrucción, divulgación o modificación de información
ción y / o denegación de servicio ”(p. 8). Una fuente de amenaza se refiere a una explotación intencional de un
vulnerabilidad, o un desencadenante accidental de una vulnerabilidad. Fuentes de amenazas comunes, como lo indica
NIST, incluyen lo siguiente: amenazas naturales, amenazas ambientales y amenazas humanas.
Para identificar posibles fuentes de amenazas aplicables a la aplicación Banner, el
Se entrevistó al personal de gestión mencionado anteriormente. Los siguientes representan la identificación de fuentes de am
tificado por la administración que potencialmente podría explotar las vulnerabilidades de la aplicación:
◾ Amenazas naturales: huracanes, terremotos e inundaciones

◾ Amenazas ambientales: fallas del sistema y paradas inesperadas
◾ Amenazas humanas: acceso no autorizado de piratas informáticos, empleados despedidos y personas con información p
empleados descontentos, maliciosos, negligentes o deshonestos)
Las motivaciones de las amenazas humanas, identificadas por la gerencia, incluyen las siguientes:
◾ Desafío, ego y rebelión (hackers)

◾ Destrucción de información, divulgación ilegal de información, ganancias monetarias y
izada alteración de datos (empleados despedidos y piratas informáticos)
◾ Curiosidad, ego, inteligencia, ganancias monetarias, venganza, errores no intencionales y omisiones
(iniciados)
Página 446
Anexo A5.2 Vulnerabilidades y fuentes de amenazas
Área de TI Vulnerabilidad Fuente de amenaza
Operaciones IS 1. No hay almacenamiento externo de datos. Huracanes, fallas del sistema,

copias de seguridad para proporcionar e inesperado
garantía de disponibilidad en caso de cierres.
un desastre.
Información 2. Varias de las contraseñas de la Universidad Usuarios no autorizados

Seguridad los ajustes configurados en Banner no son (hackers, despedido
coherente con las mejores prácticas de la industria. empleados y personas con información privilegiada
Información 3. Los propietarios de aplicaciones de banner no Usuarios no autorizados

Seguridad revise periódicamente los privilegios de acceso de los usuarios.
(hackers, despedido
empleados y personas con información privilegiada
Información 4. Las cuentas de usuario canceladas no son Usuarios no autorizados

Seguridad eliminado a tiempo, o no eliminado en absoluto, (empleados despedidos).
de Banner.
Cambio de control 5. Resultados de la prueba para las modificaciones del banner Implementación de
administración no están aprobados por la gerencia antes aplicación no autorizada
a su implementación en el modificaciones.
Paso 3. Identi cación de vulnerabilidades

NIST define la vulnerabilidad como una “debilidad en un sistema de información, procedimiento de seguridad del sistema
medidas, controles internos o implementación que podrían ser explotados por una fuente de amenaza ”(p. 9).
Las vulnerabilidades alrededor de Banner que podrían ser explotadas por fuentes de amenazas se identificaron a partir de
consultas con el personal de gestión, observaciones e inspecciones de la documentación pertinente,
según lo recomendado por NIST. La documentación revisada incluye evaluaciones previas de riesgos de TI, así
como informes de seguridad y auditoría de TI. Consulte el Anexo A5.2 para obtener una lista de cinco vulnerabilidades y am
pares de fuentes identificados por área de TI.
Paso 4. Análisis de control

Este paso toma en consideración los controles que están en su lugar o están planificados para su implementación.
por la Universidad con el fin de reducir o eliminar la probabilidad de que una amenaza ejerza una vulnerabilidad
capacidad. Este paso se aborda en los Pasos 8 y 9.
Paso 5. Determinación de probabilidad
NIST establece que se debe considerar lo siguiente para desarrollar una calificación que indique el problema
capacidad de ejercitar las vulnerabilidades:
◾ Motivación y capacidad de las fuentes de amenazas

◾ Naturaleza de la vulnerabilidad
◾ Existencia y efectividad de los controles actuales
Página 447
Figura A5.3 Niveles de probabilidad
Probabilidad
Nivel De nición de probabilidad Valor de nivel de probabilidad
Muy alto La fuente de amenazas está extremadamente motivada y muy 1,00

capaz; controles para prevenir la vulnerabilidad
de ser ejercitados son inexistentes.
Alto La fuente de amenazas está muy motivada y 0,75

suficientemente capaz; controles para prevenir
la vulnerabilidad de ser ejercida son
ineficaz.
Medio La fuente de la amenaza está motivada y es capaz; 0,50

existen controles que pueden prevenir
ejercicio exitoso de la vulnerabilidad.
Bajo La fuente de la amenaza carece de motivación o capacidad; 0,25

existen controles para prevenir (o al menos impedir)
la vulnerabilidad de ser ejercitada.
Muy bajo No hay una motivación de fuente de amenaza o 0,10

capacidad; controles en su lugar previenen la
vulnerabilidad de ser ejercida.
NIST recomienda las siguientes definiciones Alto-Medio-Bajo para describir la probabilidad de que
las vulnerabilidades pueden ser ejercidas por una fuente de amenaza determinada. Sin embargo, para este ejemplo, Muy alto
y se han agregado niveles muy bajos para obtener una calificación más granular que indica la probabilidad
que pueden ejercitarse las vulnerabilidades. Consulte el Anexo A5.3.
Probabilidades de muy alta = 1,00, alta = 0,75, media = 0,50, baja = 0,25 y muy
Bajo = 0.10 fueron asignados para cada vulnerabilidad en base a la estimación de la administración de su similar.
nivel de vida.
Paso 6. Análisis de impacto

Según NIST, el análisis de impacto determina el efecto adverso en el sistema de TI resultante de
amenazas que ejercen con éxito las vulnerabilidades. No se puede medir la magnitud del impacto
en unidades específicas, pero se pueden clasificar como Alto, Medio o Bajo, según lo recomendado por NIST. En
En este ejemplo, también se incorporaron magnitudes Muy Alta y Muy Baja para obtener una mayor
nivel de impacto detallado de las amenazas que ejercen con éxito las vulnerabilidades. Consulte el Anexo A5.4.
Paso 7. Determinación del nivel de riesgo

La determinación del nivel de riesgo para un par particular de vulnerabilidad / amenaza que se puede ejercer considera:
◾ La probabilidad de que una fuente de amenaza intente ejercer una vulnerabilidad;

◾ La magnitud del impacto de una fuente de amenaza que ejerce con éxito la vulnerabilidad; y
◾ La idoneidad de los controles planificados o existentes para mitigar o eliminar los riesgos identificados.
Página 448
Figura A5.4 Criterios de magnitud del impacto
Magnitud Nivel de impacto

de impacto Definición de impacto Valor
Muy alto Da lugar a la pérdida de activos o recursos a precios muy elevados; 100
violará o dañará la reputación de la Universidad.
Alto Resulta en la pérdida de activos tangibles de alto precio 75

o recursos; violar o dañar significativamente la Universidad
reputación.
Medio Da lugar a la pérdida de activos o recursos tangibles costosos; 50

violar o dañar la reputación de la Universidad.
Bajo Da lugar a la pérdida de algunos activos o recursos tangibles; 25

afectar notablemente la reputación de la Universidad.
Muy bajo Casi sin pérdida de activos o recursos tangibles; apenas afecta 10
la reputación de la Universidad.
La determinación de los niveles de riesgo (es decir, calificación de riesgo) se obtiene multiplicando las calificaciones asigna
probabilidad de amenaza (es decir, probabilidad) y el impacto de la amenaza. Determinación de estos niveles o ratios de ries
es de naturaleza subjetiva, ya que resulta únicamente de las estimaciones y opiniones de la dirección (basadas
sobre el conocimiento y / o experiencia previa) al asignar la probabilidad y el impacto de la amenaza. Anexo A5.5
muestra varios grados o niveles de riesgo, basados en NIST, a los que un sistema de TI (en este caso Banner)
podrían estar expuestos si una vulnerabilidad determinada fuera ejercida por una amenaza. El cuadro A5.5 también sugiere l
acciones necesarias que la gerencia debe tomar para cada nivel de riesgo. Para los propósitos de este ejemplo, Very
Se incorporaron niveles de riesgo alto y muy bajo en un esfuerzo por obtener la granularidad de las calificaciones de riesgo.
El Anexo A5.6 ilustra la finalización de los Pasos 1 a 7 antes mencionados, incluida una descripción de
cada riesgo identificado, así como la determinación final de sus niveles (es decir, calificación de riesgo) para cada vulnerabil
habilidad que podría potencialmente ejercitarse.
Figura A5.5 Niveles de riesgo
Nivel de riesgo Calificación de riesgo Descripción de riesgos y acciones necesarias
Muy alto 100 Las medidas correctivas son obligatorias; los planes de acción deben ser
implementado; Es posible que el sistema de TI no funcione.
Alto 75 Fuerte necesidad de medidas correctivas; el sistema de TI puede

continuar operando, pero se debe establecer un plan de acción correctiva
implementado inmediatamente.
Medio 50 Se necesitan acciones correctivas; se debe implementar un plan
para incorporar las acciones necesarias dentro de un razonable
período de tiempo.
Bajo 25 La gerencia debe determinar si las acciones correctivas

todavía se requieren, o deciden aceptar el riesgo.
Muy bajo 10 Es posible que no se necesiten acciones correctivas, ya que los riesgos identificados
puede ser aceptable.
Página 449
Figura A5.6 Evaluación de riesgos
Probabilidad Magnitud Nivel de impact

Área de TI Vulnerabilidad Fuente de amenaza Nivel Probabilidad de impacto Valor
Operaciones IS 1. No hay Huracanes Medio 0,50 Alto 75

- Fuera del sitio almacenamiento fuera del sitio
fallas del sistema,
Almacenamiento para copias de seguridad dee datos
inesperado
Para proveer cierres.
razonable
garantía de
disponibilidad en
el evento de un
desastre.
Información 2. Varios de los No autorizado Alto 0,75 Alto 75

Seguridad Universidad usuarios (hackers,
- contraseñas contraseña terminado
ajustes empleados, y
configurado en iniciados).
Banner no es
consistente con
mejor de la industria
prácticas.
Información 3. Banner No autorizado Muy alto 1,00 Alto 75

Seguridad solicitud usuarios (hackers,
- Reseñas de los propietarios no terminado
Acceso de usuario periódicamente empleados, y
revisar usuario iniciados).
acceso
privilegios.
Página 450
Anexo A5.6 ( continuación ) Evaluación de riesgos
Probabilidad Magnitud Nivel de impact

Área de TI Vulnerabilidad Fuente de amenaza Nivel Probabilidad de impacto Valor
Información 4. Usuario rescindido No autorizado Muy alto 1,00 Alto 75

Seguridad - las cuentas no son usuarios
Terminaciones eliminado a tiempo, (terminado
o no eliminado empleados).
en absoluto, desde
Bandera.
Cambio 5. Resultados de la prueba para

Implementación Bajo 0,25 Alto 75
Controlar Bandera de no autorizado
administración modificaciones solicitud
no son modificaciones.
aprobado por
administración,
antes de su
implementación
en el
producción
medio ambiente.
Página 451
Como se mencionó anteriormente, los Pasos 4, 8 y 9 se relacionan con la identificación e implementación de

controles que mitigan o reducen riesgos, así como documentación de resultados. Estos pasos se tratan en
las siguientes secciones.
Paso 8. Recomendaciones de control

Proceso de mitigación de riesgos
La mitigación de riesgos constituye la segunda mitad de la metodología de gestión de riesgos. Según NIST, organización
La gerencia de las operaciones debe seleccionar un enfoque de costos razonable y efectivo para implementar
control de TI para reducir los riesgos identificados a niveles aceptables. El Anexo A5.7 describe el
opciones disponibles para la mitigación de riesgos y la estrategia de gestión de riesgos.
En conversaciones con la gerencia de la Universidad, se acordó que la Planificación de Riesgos era la
opción seleccionada para mitigar los riesgos identificados. Por lo tanto, la estrategia de mitigación implicó la preparación
elaborar un plan que priorice, implemente y mantenga los controles necesarios para abordar
riesgos. La gerencia entendió que era apropiado implementar controles para abordar los riesgos cuando
las vulnerabilidades pueden ser ejercidas por amenazas. Es decir, el plan de la gerencia, siguiendo el NIST, era incorporar
Mejorar la seguridad y la protección mediante la implementación de controles para minimizar los riesgos o prevenirlos.
Enfoque para la recomendación / implementación de control

Con el fin de seleccionar e implementar controles para abordar los riesgos, la administración adoptó el NIST-
enfoque recomendado para la implementación del control. El enfoque comienza priorizando y
evaluar los controles recomendados (RC) seguido de su selección formal e identificación de
riesgos residuales. El enfoque recomendado por NIST ayuda a implementar controles que pueden reducir
los riesgos asociados con Banner.
Priorización y controles recomendados

La priorización, según NIST, se refiere al proceso de establecer la importancia de los riesgos
identificadas y los RC para mitigación. Basado en la importancia de los riesgos identificados, el control
Figura A5.7 Opciones de mitigación de riesgos
Asunción de riesgo Acepta riesgos potenciales y continúa con las operaciones de TI.
Evitación de riesgo Evita el riesgo eliminando su causa y / o consecuencia.
Limitación de riesgo Limita los riesgos mediante la implementación de controles que minimizan el impacto de un
vulnerabilidad ejercida por una amenaza.
Planificación de riesgos Gestiona los riesgos mediante un plan de mitigación de riesgos que prioriza,
implementa y mantiene controles.
Investigación y Reducir los riesgos de pérdida al reconocer las vulnerabilidades e investigar

Reconocimiento controles para corregirlos.
Transferencia de riesgo Transfiere el riesgo para compensar pérdidas potenciales.
Página 452
se establecen recomendaciones. La gerencia enumeró todos los RC potenciales que podrían reducir la
riesgos identificados y asignados prioridad a esos controles utilizando clasificaciones que van desde Muy alto
a niveles muy bajos (consulte el Anexo A5.8). La gerencia también reconoció que implementar todos
Los CR pueden no ser la opción más apropiada y factible. Análisis adicionales relacionados con la viabilidad,
eficacia y costo-beneficio se realizaron en las siguientes secciones para cada CR con el fin de
Determinar los más adecuados para reducir riesgos.
Evaluaciones de viabilidad y eficacia de los controles recomendados

La gerencia reconoció que el proceso de recomendación de control implica seleccionar una combinación
de los controles de las categorías técnicas, de gestión y operativas que podrían reducir
riesgos alrededor de Banner. Las siguientes son descripciones de cada categoría de control basadas en NIST.
◾ Controles de seguridad de gestión . Estos controles gestionan y reducen el riesgo de pérdida mientras se
proteger la misión de la organización. Los controles de seguridad de gestión adoptan la forma de políticas,
directrices y estándares para cumplir con las metas y misiones de la organización.
◾ Controles técnicos de seguridad . Estos controles se relacionan con la configuración de parámetros dentro
aplicaciones, sistemas, bases de datos y redes para protegerse contra las amenazas de seguridad durante
información sensible y cal, así como funciones del sistema de TI.
Figura A5.8 Controles recomendados y prioridad asignada
Acción
Área de TI Riesgo Control de nivel de riesgo recomendado (RC) Prioridad
Operaciones IS - 1. Información del banner Medio RC1. Backups de Banner Medio

Fuera del sitio no se puede recuperar los datos financieros se archivan
Almacenamiento en el caso de un fuera del sitio para minimizar el riesgo
fallo de sistema, esos datos se pierden.
impactando el
La capacidad de la universidad para
informe financiero
información
de acuerdo a
establecido
reportando
requisitos.
Información 2. Parámetros de seguridad Alto RC2. La identidad de los usuarios es Alto

Seguridad - no son autenticado en Banner
Contraseñas adecuadamente a través de contraseñas
configurado, coherente con la industria
permitiendo mejores prácticas mínimo
potencial valores de seguridad. Contraseñas
usuario no autorizado debe incorporar
acceso al configuración para mínimo
Aplicación de banner. longitud, cambio periódico,
historial de contraseñas, bloqueo
umbral y complejidad.
( Continuacion )
Página 453
Figura A5.8 ( continuación ) Controles recomendados y prioridad asignada
Acción
Área de TI Riesgo Control de nivel de riesgo recomendado (RC) Prioridad
Información 3. Los usuarios poseen RC3 muy alto. Propietarios de banners Muy
Seguridad - privilegios que son autorizar la naturaleza y Alto
Reseñas de no es consistente con grado de acceso del usuario
Acceso de usuario sus funciones laborales, privilegios.
permitiendo RC4. La habilidad de hacer
no autorizado o modificaciones a Banner
incorrecto parámetros de seguridad,
modificaciones a roles de seguridad, o seguridad
Los datos del banner que la configuración está limitada a
Podría causar personal apropiado.
administración RC5. Privilegios de acceso de usuario
decisiones basadas dentro de Banner son
al engañar revisado periódicamente por
información. propietarios de aplicaciones para
verificar ese acceso
los privilegios permanecen
apropiado y
consistente con el trabajo
requisitos.
Información 4. Usuarios cesados RC6 muy alto. La seguridad Muy

Seguridad - puede acceder a se notifica al administrador Alto
Terminaciones Banner y ver o de empleados que tienen
modificar su financiera ha sido terminado. Acceso
información. privilegios de tal
los empleados son
inmediatamente cambiado a
Cambio 5. Banner Bajo RC7. Modificaciones a Bajo

Controlar las modificaciones son Banner son probados y
administración no adecuadamente aprobado por la gerencia
autorizado. antes de su
Implementación de implementación en
tales modificaciones producción de acuerdo
podría resultar en con planes de prueba y resultados.
inválido o RC8. Usuario y otros
datos engañosos. solicitudes de modificaciones
a Banner, incluido
actualizaciones, correcciones y
cambios de emergencia, son
documentado y aprobado
por la gerencia para verificar
que todo cambia a la
entorno de producción
fueron documentados, probados,
y autorizado.
Página 454
◾ Controles de seguridad operacional . Estos controles aseguran que los procedimientos de seguridad gobiernen
El control del uso de los activos de TI de la organización (es decir, Banner) se implementan adecuadamente.
coherente con los objetivos y la misión de la organización. Dirección de controles de seguridad operacional
deficiencias operativas que podrían resultar de vulnerabilidades potencialmente ejercidas.
La determinación de la categoría y las discusiones de cada RC por área de TI se realizaron con el asistente
tancia de la gestión y se documentan en el Anexo A5.9.
Análisis de costo-beneficio para los controles recomendados

El análisis de costo-beneficio debe realizarse después de la identificación de los CR y la evaluación de sus
viabilidad y eficacia. El objetivo del análisis de costo-beneficio es respaldar que el costo
de implementar el control se justifica por una reducción en el nivel de riesgo. Es decir, costo-beneficio
Los análisis deben garantizar
La administración queapropiado
entendió los controles se implementen
que los beneficios dede
losmanera rentable.
controles seleccionados deben ser evaluados
valorado en términos de su impacto en la reducción de riesgos. En la misma línea, el efecto de no implementar
los controles deben evaluarse para respaldar si Banner puede continuar operando de manera efectiva sin
implementar los controles. La gerencia debe determinar el nivel mínimo de aceptabilidad
para los riesgos identificados, así como el impacto de cada control seleccionado para determinar su efecto en
Bandera. Las evaluaciones de los controles potenciales en relación con los riesgos se pueden realizar siguiendo las
reglas a continuación, según lo sugerido por NIST:
◾ Regla 1. Si el control reduce los riesgos más de lo necesario, considere una alternativa, menos costosa
controlar.
◾ Regla 2. Si el costo del control es mayor que la reducción de riesgo provista, considere identificar
fying controles adicionales.
◾ Regla 3. Si el control no proporciona una reducción significativa del riesgo, considere identificar
controles adicionales.
◾ Regla 4. Si el control proporciona una reducción significativa del riesgo y es rentable, imple-
ment el control.
A continuación se muestra un resumen general de los procedimientos de análisis de costo-beneficio realizados para
cada RC:
◾ Evaluó el impacto de implementar versus no implementar el CR.

◾ Estimó el costo de implementación teniendo en cuenta los siguientes factores, según corresponda:
- Se requieren compras adicionales de hardware y software.
- Reducción de la eficacia operativa resultante de la falta de implementación.
- Reducción del rendimiento, la funcionalidad o la seguridad del sistema debido a la falta de implementación.
- Costo de implementar políticas, procedimientos, estándares nuevos / revisados, etc.
- Costo de contratación (o capacitación) de personal para implementar RC.
◾ Evaluar los beneficios potenciales sobre los costos para respaldar la implementación del nuevo control, y
comunicarlo a la alta dirección y al Consejo de Administración de la Universidad.
Una vez realizado el análisis de costo-beneficio, los controles se seleccionaron formalmente (consulte el Anexo
A5.10). Sin embargo, debido a que los riesgos no se pueden eliminar por completo, sino reducir a niveles aceptables,
Página 455
Anexo A5.9 Control recomendado: Determinación y discusión de categorías
Área de TI: Control recomendado Categoría de control y discusi
Operaciones de SI - Almacenamiento externo: RC1 es parte de los controles de seguridad de gestión y la seguridad op
RC1. Las copias de seguridad de los datos financieros de Banner son Controla las categorías. RC1 tiene la capacidad de apoyar la continui
archivados fuera del sitio para minimizar el riesgo de que los datos y reanudación del negocio durante emergencias o desastres. Igualmen
perdió. asegura que los datos respaldados de Banner se roten a una ubicación
minimizar el riesgo de que se pierdan datos importantes durante un ev
falla de hardware, desastre del entorno informático, etc.). La recupera
podría requerir un esfuerzo significativo o ser virtualmente imposible
Seguridad de la información - Contraseñas: RC2 pertenece a la categoría de controles técnicos de seguridad. Auten
RC2. La identidad de los usuarios se autentica para controles a través de la configuración de la configuración de segurida
Banner a través de contraseñas coherentes con identidad del empleado para garantizar que sea válida y genuina. Más
mejores prácticas de la industria seguridad mínima Los controles de contraseña promueven la seguridad adecuada y prot
valores. Las contraseñas deben incorporar de amenazas, como ataques deliberados de personas malintencionada
configuración para longitud mínima, periódica empleados que intentan obtener acceso no autorizado para comprome
cambio, historial de contraseñas, umbral de bloqueo, integridad, disponibilidad o confidencialidad de los datos. Las contra
y complejidad. Información financiera de Banner de actos no intencionales, como ne
para eludir la seguridad del sistema.
Seguridad de la información: revisiones del acceso de los usuarios: RC3, RC4 y RC5 pertenecen a los controles de seguridad de gestión, a
RC3. Los propietarios de carteles autorizan la naturaleza y Categorías de controles técnicos de seguridad. Se aseguran de que el
extensión de los privilegios de acceso del usuario. concedido siguiendo el principio de "privilegio mínimo" (también co
RC4. La capacidad de realizar modificaciones en Banner. privilegio mínimo), que básicamente requiere que los usuarios deben
parámetros de seguridad, roles de seguridad o seguridad información y recursos necesarios para llevar a cabo sus tareas diaria
la configuración está limitada a la apropiada El acceso otorgado a los usuarios debe ser legítimo y coherente con l
personal. No revisar los niveles de acceso de los usuarios de forma periódica p
RC5. Los privilegios de acceso de usuario dentro de Banner son detectar y corregir el acceso no autorizado de manera oportuna.
revisado periódicamente por los propietarios de la aplicación para
verificar que los privilegios de acceso sigan siendo apropiados
y coherente con los requisitos del trabajo.
Página 456
Anexo A5.9 ( continuación ) Control recomendado: Determinación y discusión de categorías
Área de TI: Control recomendado Categoría de control y discusi
Seguridad de la información - Terminaciones: RC6 pertenece a la categoría de controles técnicos de seguridad. Notif
RC6. Se notifica al administrador de seguridad de las renuncias o terminaciones deben comunicarse, oportunamente, a T
empleados que han sido despedidos. Acceso personal y debe incluir sistemas y / o aplicaciones específicas para qu
Los privilegios de dichos empleados son inmediatamente ser eliminado con precisión. No notificar al personal de TI puede resu
cambiado para reflejar su nuevo estado. empleados que tienen derechos de acceso capaces de ejecutar diferen
transacciones, exponiendo a la Universidad a ataques maliciosos, dañ
apropiación indebida de activos. Además, tener cuentas activas de ca
empleados dentro de Banner por un período más largo de lo necesario
manipulación de información confidencial y / o sensible, brechas de s
puede resultar en ex empleados con derechos de acceso potenciales p
tipos de transacciones (por ejemplo, contabilidad fraudulenta, desemb
Gestión de control de cambios: RC7 y RC8 forman parte de la categoría de controles de seguridad de g
RC7. Las modificaciones al Banner se prueban y Es fundamental contar con sistemas altamente confiables que cumpla
aprobado por la gerencia antes de su Universitario y debe formalizarse mediante la documentación adecua
implementación en producción de acuerdo necesario que cada cambio sea controlado a lo largo de su ciclo de vi
con planes de prueba y resultados. el entorno de producción de forma sistemática y controlada. El prima
RC8. Usuario y otras solicitudes de modificaciones El objetivo es mantener la integridad y fiabilidad del entorno de prod
a Banner, incluidas actualizaciones, correcciones y mientras realiza cambios para la comunidad de usuarios. No hacer cu
cambios de emergencia, están documentados y Los controles pueden resultar en interrupciones operativas, rendimien
aprobado por la gerencia para verificar que todos seguridad comprometida. Además, la falta de documentación puede r
Los cambios en el entorno de producción fueron para rastrear dónde se han realizado los cambios, retrasando así la co
documentado, probado y autorizado. La documentación adecuada respalda los resultados de las pruebas, in
encontrado, así como las aprobaciones para implementar cambios en
Página 457
Anexo A5.10 Selección de controles, resultados y riesgos residuales
Área de TI Riesgo Control seleccionado
Operaciones IS - 1. La información del banner no se puede RC1. Copias de seguridad de los datos financieros de B
Almacenamiento externo recuperado en caso de un sistema se archivan fuera del sitio para minimizar el riesgo
fracaso, impactando la Universidad esos datos se pierden.
capacidad para reportar información financiera
según informes establecidos
requisitos.
Información 2. Los parámetros de seguridad no son RC2. La identidad de los usuarios es

Seguridad - apropiadamente configurado, permitiendo autenticado a Banner a través de
Contraseñas posible acceso de usuarios no autorizados a contraseñas consistentes con las mejores de la industri
la aplicación Banner. practica valores mínimos de seguridad.
Las contraseñas deben incorporar
configuración para longitud mínima,
cambio periódico, historial de contraseñas,
umbral de bloqueo y complejidad.
Información 3. Los usuarios poseen privilegios que no RC5. Privilegios de acceso de usuario dentro
Seguridad - coherente con sus funciones laborales, Los banners son revisados periódicamente por
Reseñas de permitiendo no autorizado o incorrecto propietarios de aplicaciones para verificar ese acceso
Acceso de usuario modificaciones a los datos de Banner que los privilegios siguen siendo apropiados y
podría causar decisiones de gestión coherente con los requisitos del trabajo.
basado en información engañosa.
Información 4. Los usuarios cancelados pueden acceder a RC6. El administrador de seguridad es

Seguridad - Banner y ver o modificar su información financiera. notificados de los empleados que han sido
Terminaciones información. terminado. Privilegios de acceso de tales
los empleados se cambian inmediatamente a
Cambio de control 5. Las modificaciones del banner no son RC7. Se prueban las modificaciones al Banner
administración debidamente autorizado. Implementación y aprobado por la gerencia antes de
de tales modificaciones podría resultar en su implementación en producción en
datos inválidos o engañosos. de acuerdo con los planes de prueba y los resultados.
Página 458
había algunos riesgos que aún permanecían después de la selección e implementación formal de los controles.
Estos riesgos restantes se denominan "riesgos residuales" y se analizan a continuación.
Resumen de riesgo residual

NIST declara que ningún sistema de TI, incluidos sus sistemas y aplicaciones, está libre de riesgos. A pesar de que
Los controles implementados pueden mitigar o reducir los riesgos, simplemente no pueden eliminar todos los riesgos. Cualq
que queda después de la implementación de controles nuevos o mejorados se conoce como riesgo residual. NIST
también establece que las reducciones en los riesgos resultantes de controles nuevos o mejorados pueden ser analizados por
organizaciones en términos de la probabilidad de amenaza reducida o el impacto, ya que estos dos parámetros definen
el nivel de riesgo mitigado para la organización. NIST sugiere además que la implementación de
Los controles nuevos o mejorados pueden mitigar los riesgos al:
◾ eliminar vulnerabilidades mediante la minimización de posibles pares de amenaza-fuente / vulnerabilidad;

◾ agregar controles específicos para reducir las capacidades y motivaciones de las fuentes de amenazas; y por
◾ reducir la magnitud del impacto adverso mediante la limitación del alcance de las vulnerabilidades.
El Cuadro A5.11 ilustra la relación entre la implementación del control y el riesgo residual.
El Paso 9 describe los resultados de esta evaluación de riesgos, incluidos los riesgos residuales que quedan en
Banner después de que se haya aplicado la mitigación, así como un plan para gestionar dichos riesgos residuales.
Paso 9. Documentación de resultados

Como se indicó anteriormente, los controles implementados pueden reducir los riesgos, pero no necesariamente eliminarlos.
Los riesgos residuales pueden permanecer después de que todos los demás riesgos conocidos se hayan contrarrestado, factor
exponer a la organización a pérdidas.
El Anexo A5.10 muestra el efecto de implementar controles sobre los riesgos identificados, como
cated por la gerencia. A continuación se resume dicho efecto una vez que los controles seleccionados fueron
implementado:
Eliminando o
reduciendo
vulnerabilidades
Nuevo o mejorado Cualquier restante

Añadiendo objetivo
los controles mitigan el riesgo se llama:
control S
riesgos por riesgo residual
Reducir magnitud
de impacto
Anexo A5.11 Implementación de control y riesgo residual nuevos o mejorados.
Página 459
◾ Riesgo 1, Riesgo 4 y Riesgo 5 relacionado con la recuperación de datos de Banner, acceso a cuentas de usuario cancela
y la implementación no autorizada de cambios de Banner, respectivamente, se redujeron a aceptables
niveles sin riesgos residuales restantes. No se consideró necesario ningún otro procedimiento.
◾ Riesgo 2, relacionado con la configuración de parámetros de seguridad inapropiados (es decir, contraseñas), también
ya que el Riesgo 3 (es decir, inconsistencias en el acceso de los usuarios) no se redujo a niveles aceptables, lo que
en algunos riesgos residuales que quedan, que se analizan a continuación.
Para el riesgo 2, la administración configuró tres de cada cinco parámetros de contraseña (es decir, longitud mínima,
historial de contraseñas y umbral de bloqueo). Sin embargo, el cambio de contraseña periódico y la complejidad
los ajustes no fueron configurados. La gerencia reconoce que el cambio de contraseña periódico (o contraseña
caducidad de la palabra) y la complejidad pueden ser una fuente de frustración para los usuarios, que a menudo necesitan
para crear y recordar nuevas contraseñas cada pocos meses para varias cuentas. Por tanto, los usuarios
tienden a elegir contraseñas débiles y usan las mismas pocas contraseñas para muchas cuentas. administración
declaró además que los costos de configurar estas dos configuraciones de contraseña no eran justificables. Como
como resultado, seguía existiendo un riesgo residual que exponía los datos financieros de Banner a amenazas como
ataques, daños, intrusiones y / o manipulación.
Después de varias discusiones sobre los riesgos residuales, la gerencia expresó interés en
mejorar la configuración actual de la contraseña de Banner en un futuro próximo. Mientras tanto, lo siguiente
constituye el plan de la administración y las salvaguardas actuales para manejar y / o mitigar los
riesgos relacionados con el riesgo 2:
◾ Los ajustes de contraseña actuales configurados en la red de área local (LAN) son coherentes con
las mejores prácticas de la industria y la configuración de direcciones, como la longitud mínima, el historial de contra
umbral de bloqueo, cambio de contraseña y complejidad. Este control actual ayuda a gestionar
y mitigar el riesgo residual en Banner, ya que los usuarios deben autenticarse en la LAN antes
acceder a la aplicación Banner. La LAN sirve como primer nivel de autenticación para
Los usuarios de banners y esas configuraciones se configuran de manera efectiva.
◾ Las herramientas de seguridad de la información sobre Banner se administran e implementan para restringir el acceso,
así como, registrar e informar eventos de seguridad (por ejemplo, informes de violaciones de seguridad,
intentos de acceder a recursos de información, etc.).
◾ Los propietarios de aplicaciones de banner autorizan el acceso a nuevos usuarios y / o usuarios que han cambiado
funciones y responsabilidades.
◾ Los usuarios de banners deben tener un identificador de usuario único para distinguir a un usuario
de otro y para establecer la responsabilidad.
◾ Las terminales de pancartas y las estaciones de trabajo están protegidas por instalaciones de tiempo límite, que se activ
después de que haya transcurrido un período de inactividad predeterminado y apropiado.
Con respecto al Riesgo 3, la gerencia indicó que solo una revisión de acceso de usuario continuaría siendo
realizadas durante el año, ya que el costo de realizar revisiones adicionales / periódicas del acceso de los usuarios es
no justificable. Como resultado, los siguientes riesgos residuales permanecieron reconocidos por la gerencia:
1. La falta de revisiones periódicas de los niveles de acceso de los usuarios puede resultar en que los empleados tengan d
registrar y autorizar diferentes tipos de transacciones (por ejemplo, transacciones contables, diario
entradas, etc.), exponiendo así a la Universidad a un riesgo de fraude, manipulación de la información,
o apropiación indebida y errores.
2. Si no se revisan los niveles de acceso de los usuarios de forma periódica, es posible que la Universidad no detecte
y corregir el acceso no autorizado de manera oportuna.
Página 460
Con el fin de elaborar un plan para identificar salvaguardas para gestionar y / o mitigar tales
riesgos, la dirección señaló los siguientes procedimientos que se encuentran actualmente en vigor:
◾ Los propietarios de aplicaciones de banner autorizan el acceso a nuevos usuarios y / o usuarios que han cambiado
funciones y responsabilidades.
◾ La capacidad de realizar modificaciones en los parámetros de seguridad de Banner, roles de seguridad o seguridad.
la configuración está limitada al personal apropiado.
◾ Las herramientas de seguridad de la información sobre Banner se administran e implementan para restringir el acceso,
así como registrar e informar eventos de seguridad (por ejemplo, informes de violaciones de seguridad,
intentos de acceder a recursos de información, etc.).
◾ Existen procedimientos efectivos para asegurar que los sistemas de producción estén disponibles para
la ejecución del procesamiento y que los datos financieros se puedan recuperar en caso de interrupciones
en el procesamiento ocurren.
◾ Existen procedimientos de control de cambios efectivos para asegurar que las modificaciones de Banner sean
probado en un entorno de prueba / desarrollo separado antes de la implementación en la producción
medio ambiente.
La gerencia expresó además su intención de segregar a los usuarios de Banner en grupos. Un horario
estar preparado para realizar revisiones periódicas adicionales de acceso para varios grupos de usuarios durante la
año. El acceso de todos estos grupos de usuarios debe ser revisado y aprobado durante un período de dos
años. La documentación que respalde esas revisiones también se mantendrá como prueba.
Las actividades de control mencionadas anteriormente son útiles para gestionar y mitigar la
riesgos resultantes de la configuración de contraseñas, así como la falta de revisiones periódicas del acceso de los usuarios. E
salvaguardias adicionales compensan las excepciones señaladas anteriormente y pueden mitigar los riesgos de
usuarios no autorizados que acceden a los datos financieros de Banner.
En general, los resultados de este ejercicio de evaluación de riesgos fueron satisfactorios, lo que significa que los contro
funcionando con eficacia. Es decir, los controles establecidos no solo mitigan los riesgos, sino que cubren la efectividad.
y eficiencia de las operaciones, confiabilidad e integridad de los registros contables y cumplimiento
con las leyes y reglamentos aplicables, entre otros. La gerencia expresó gran satisfacción con
los resultados de los ejercicios de evaluación y mitigación de riesgos, e indicó además que los resultados
obtenidos en torno a la aplicación financiera de Banner fueron consistentes con evaluaciones de riesgo anteriores
y evaluaciones. En particular, los resultados de los ejercicios de riesgo realizados motivaron la
Gestión de TI para continuar proporcionando a los usuarios información financiera segura y confiable
protegiendo constantemente la confidencialidad, integridad y disponibilidad de la información a través de
Controles de TI.
Página 461
Apéndice 6: Cambio de muestra

Política de gestión de control
Política de gestión de control de cambios

Número de póliza: XYZ-WI-CCM-001
Versión: 1.0
Departamento: Tecnología de la información
Nombre Posición Firma Fecha
Preparado por: Gerente de TI y / o XX / XX / 20XX

Administrador
Revisado por: Director de TI XX / XX / 20XX

Infraestructura
Revisado por: Desarrollo de sistemas XX / XX / 20XX

Gerente
Aprobado por: Vicepresidente de TI XX / XX / 20XX
Misión
Promover un entorno e infraestructura de TI que sea confiable y disponible.
Propósito
El propósito de la política de Gestión del Control de Cambios es:
◾ Proporcionar una metodología formal en la que los cambios relacionados con la producción de la Organización
el medio ambiente está documentado.
◾ Exigir que los cambios se soliciten, trabajen y aprueben adecuadamente antes de su instalación.
ción o implementación en el entorno de producción.
◾ Asegúrese de que todas las partes afectadas por el cambio sean notificadas a tiempo.
◾ Asegúrese de que la instalación o implementación de los cambios esté programada y coordinada
dentro de la organización.
435
Página 462
436 ◾ Apéndice 6: Control de cambios de muestra
Alcance
Esta política cubre el proceso de gestión del control de cambios, incluida la forma en que los cambios (consulte Cambio en
Sección "Definiciones") relacionadas con sistemas operativos, aplicaciones, bases de datos, redes, hardware,
y la infraestructura (en conjunto denominados "sistemas") debe implementarse dentro de la TI
entorno de producción, o el entorno en el que se basa la Organización para llevar a cabo
operaciones comerciales normales y / o salvaguardar el entorno de TI.
De niciones
Gestión de control de cambios . Proceso implementado para promover un servicio de calidad y mejorar diariamente
operaciones de la organización. El proceso garantiza que los cambios del sistema se implementen de manera efectiva.
tiva, eficiente y consistente con el fin de reducir cualquier impacto negativo resultante de la
implementación de tales cambios.
Formulario de solicitud de cambio o CRF . Documentación formal y notificación de un cambio (y sus par-
particularidades) enviado por la persona que solicita el cambio (es decir, el Solicitante del Cambio). El CRF
sirve como comunicación escrita y acuerdo entre el solicitante y la aplicación de TI /
personal de desarrollo.
Cambiar . Modificación necesaria para transformar o alterar el entorno operativo o los procedimientos de
la organización. Un cambio podría afectar potencialmente la confiabilidad y disponibilidad de la infraestructura de TI.
estructura, entorno informático y datos utilizados en la conducción normal interna y externa
operaciones de negocios. Los cambios se pueden clasificar como normales (es decir, el impacto y el riesgo del cambio no se
importante para la organización); significativo (es decir, de alto riesgo y alto impacto para las organizaciones
usuarios); o como cambios de emergencia (es decir, cambios necesarios para corregir errores o problemas inesperados dentro
cualquier sistema de la infraestructura de TI que de otro modo resultaría en un impacto adverso para el negocio
operaciones). Consulte la sección "Tipos de cambios".
Cambie el tablero de control o CCB . Comité creado para evaluar las solicitudes de cambio para las necesidades comerciales
(por ejemplo, costo versus beneficio, prioridad, impacto potencial, etc.) y tomar decisiones sobre si
los cambios propuestos deben implementarse. Las decisiones pueden tomar la forma de recomendaciones para
implementación, análisis posterior, aplazamiento o cancelación del cambio. Es común que
CCB para reunirse dos veces al mes, o según sea necesario (como es el caso de cambios de emergencia), formar parte
en la programación de todos los cambios, y estar disponible para consultas en caso de que se produzcan cambios de emergen
necesario. Tras una evaluación exitosa, el CCB aprueba el CRF y asigna un propietario de cambio
para administrar la implementación y cierre del cambio.
Tipos de cambios
A continuación se muestra una lista de circunstancias que pueden desencadenar cambios comunes en el sistema dentro de la
◾ Actualizaciones de hardware (por ejemplo, mantenimiento periódico, necesidades específicas de los usuarios, cambios
adiciones, eliminaciones, reconfiguraciones, reubicaciones, preventivo, mantenimiento de emergencia,
instalación de servidores, etc.)
◾ Actualizaciones de software (por ejemplo, mantenimiento periódico, necesidades específicas de los usuarios, mantenim
durante un período de apagado normal, arreglos temporales o permanentes del sistema, nuevas versiones, nuevas
versiones, cambios en la tabla de la base de datos, modificaciones en las bibliotecas, cambios en el funcionamiento / p
trabajos, corrección de errores, corrección de errores, etc.)
Página 463
Apéndice 6: Control de cambios de muestra ◾ 437
◾ Compra de nuevos sistemas de hardware y / o software

◾ Implementación de sistemas de información (por ejemplo, prueba e implementación de nuevas aplicaciones
ciones, nuevos sistemas operativos, nuevas versiones, nuevos lanzamientos, conversiones de datos y / o migraciones
ciones, etc.)
◾ Sistemas de red (por ejemplo, adiciones, modificaciones y / o eliminaciones de líneas de red, enrutadores,
acceso a la red, servidores, acceso de usuarios, etc.)
◾ Cambios ambientales (por ejemplo, responder a interrupciones repentinas o fallas en el suministro eléctrico,
sistemas de suministro de energía interrumpible, generadores, aire acondicionado, trabajo eléctrico, mantenimiento de
mantenimiento, sistemas de seguridad, sistemas de control de incendios, etc.)
Responsabilidades
Los usuarios de la organización son responsables de utilizar el CRF al abordar los cambios del sistema. La cosa
La responsabilidad del departamento es guiar el proceso de cambio (asegurando el cumplimiento de los requisitos del usuari
mentos) mientras se mantiene una estrecha comunicación con los solicitantes, el personal de TI y la administración
durante el proceso de modificación, prueba e implementación. A continuación se describen las
responsabilidades para cada rol.
Solicitante de cambio
Usuario responsable de iniciar y enviar la solicitud de cambio. La solicitud se envía al Cambio
Regístrese usando el formulario requerido (es decir, CRF).
Cambiar registro
Recibe el CRF enviado por el Solicitante de cambios. Una vez recibido, evalúa el cambio.
solicitud para garantizar la exactitud e integridad de toda la información necesaria relacionada con el cambio.
Las responsabilidades del registro de cambios incluyen:
◾ Clasificar la solicitud de cambio según el tipo de cambio (consulte "Tipos de cambios"

sección).
◾ Clasificar la solicitud según los requisitos comerciales y las políticas establecidas
como normal, significativo o de emergencia (consulte Cambio en la sección “Definiciones”). Si
el cambio se clasifica como un cambio de emergencia, se refiere al Control de Cambios (o
Gerente de proyecto. Dependiendo de cuán crítico sea el cambio, el Control de Cambios (o Proyecto)
El gerente llevará a cabo reuniones, según corresponda, para discutir el cambio de emergencia y para
obtener las autorizaciones necesarias para su ejecución inmediata.
◾ Evaluar el cambio para determinar el impacto operativo, los riesgos y la prioridad. El registro de cambios
Identificará el impacto del cambio en la infraestructura, los sistemas y las aplicaciones, verificando que
todos los equipos (por ejemplo, software, hardware, etc.) necesarios para trabajar con el cambio están disponibles,
así como realizar las evaluaciones o riesgos necesarios (es decir, beneficios de riesgo y análisis de riesgo) relacionado
al cambio. El registro de cambios también determinará la prioridad en función de los resultados de la
impacto y urgencia del cambio, así como la evaluación del riesgo. La prioridad contará
para el número de usuarios afectados, recursos de TI requeridos, sistemas involucrados, horas requeridas, etc.
◾ Al determinar que toda la información de la solicitud de cambio es precisa y completa, el
Register envía el CRF al revisor de control de cambios para su revisión y aprobación.
Página 464
438 ◾ Apéndice 6: Control de cambios de muestra
Revisor de control de cambios

Recibe el CRF completo para su revisión del Registro de cambios. Incluye responsabilidades:
◾ Asegurarse de que toda la documentación sea completa y precisa, que el CRF incluya un
descripción del cambio, la justificación comercial y el impacto si no se implementa, y
que todas las partes pertinentes sean conscientes de cualquier posible impacto. El revisor de control de cambios
también revisa y corrobora que la documentación relacionada con el tipo de cambio, clasificación,
El impacto operativo, el riesgo y la prioridad son completos y precisos.
◾ Si el CRF está incompleto o necesita información / justificación adicional, se enviará
Volver a ambos, Solicitante de cambio y Registro de cambio, indicando la falta o inexactitud
información de tasa. Una vez que el CRF ha sido revisado y modificado según sea necesario, el cambio
El registro lo vuelve a enviar al revisor de control de cambios.
◾ Si el CRF es exacto y completo, el revisor de control de cambios lo reenvía al
Gerente de Control de Cambios (o Proyecto) para su aprobación.
Gerente de Control de Cambios (o Proyecto)

El administrador de control de cambios (o proyecto) supervisa todo el programa de gestión de control de cambios.
ceso, y es responsable de su mejora continua. Otras responsabilidades incluyen:
◾ Evaluar el CRF y determinar el impacto potencial en el departamento que solicita

cambio, así como a toda la infraestructura de la organización.
◾ Notificar a todas las partes afectadas sobre el próximo cambio y sobre posibles conflictos que
necesitará resolución.
◾ Coordinar, programar y realizar reuniones con el CCB relacionadas con el cambio
gestión de controles, específicamente para evaluar, aprobar, autorizar y / o rechazar la solicitud
cambio (s).
◾ Agrupar todos los CRF pendientes en espera de evaluación o consideración o acción adicionales.
◾ Una vez que se aprueba la solicitud, el Gerente de Control de Cambios (o Proyecto) coordina para
puerto, si es necesario, para resolver los problemas identificados o para responder cualquier pregunta durante o inmed
Inmediatamente después de la instalación / implementación.
◾ Con la ayuda de los miembros de CCB, el Gerente de Control de Cambios (o Proyecto) revisa
implementado cambios para asegurar el cumplimiento de los objetivos, e identificar acciones y
oportunidades para corregir problemas y mejorar la calidad del servicio, respectivamente. El cambio
El Gerente de Control (o Proyecto) identifica y remite cualquier cambio que haya fallado o
ha sido retirado.
Cambio de propietario
El propietario del cambio es responsable de la planificación, administración, ejecución e implementación efectivas.
mentación de todos los cambios aprobados. Él o ella prepara y envía el plan de implementación a
el equipo de implementación para la construcción, prueba y validación del cambio. El plan incluye
la programación de recursos y la asignación de tareas requeridas. Otras tareas incluyen:
◾ Recibir CRF aprobados del CCB.

◾ Comunicar la fecha final de implementación al Gerente de Control de Cambios (o Proyecto).
Página 465
Apéndice 6: Control de cambios de muestra ◾ 439
◾ Actualización de los CRF, si es necesario.

◾ Instruir al equipo de implementación para que proceda con la implementación del cambio.
◾ Identificar si alguno de los cambios se clasifica como cambios de emergencia. Nota: Emergencia
Los cambios están sujetos a las mismas actividades de prueba o garantía de calidad que los cambios normales, except
que los controles, las tareas de supervisión y los planes / procedimientos de reversión deben estar en su lugar en todo
para proteger el entorno de producción de actualizaciones no autorizadas.
◾ Obtener aprobaciones antes de la implementación del cambio en el entorno de producción.
mentos. Estas aprobaciones finales se relacionan con:
- Finalización de todas las pruebas, incluida la documentación de los resultados de las pruebas efectivas
- Fecha de implementación
- Seguro de calidad
- Completar toda la documentación relacionada con el cambio (p. Ej., Materiales de capacitación / usuario, configura
ración de seguridad de la información, procedimientos de respaldo y restauración, etc.).
◾ Comunicar los problemas identificados al Gerente de Control de Cambios (o Proyecto) y
juntos determinan si la implementación del cambio aprobado debe continuar o no. Si
la implementación del cambio no debe continuar, entonces el cambio debe revertirse. Si
la implementación del cambio es exitosa, el propietario del cambio actualiza el CRF con resultados.
◾ Realizar revisiones del cambio después de la implementación (es decir, revisiones posteriores a la implementación).
Estas revisiones abordan, entre otros, si:
- el cambio cumplió o no sus objetivos originales;
- la implementación del cambio se realizó según lo programado y dentro del presupuesto;
- todas las partes afectadas fueron debidamente informadas sobre el progreso, la fecha de implementación y los resul
de la implementación; y
- la implementación del cambio fue revertida o no (si es así, documentación, como CRF
deben revisarse y actualizarse adecuadamente).
◾ Informar y discutir los resultados generales de la implementación del cambio con ambos,
Gestor de Control de Cambios (Proyecto) y CCB.
◾ Cerrar el CRF.
Revisión
Versión Descripción de la revisión realizada Interpretado por Fecha
1,00 XX / XX / 20XX
Página 467
466
Apéndice
Sistemas de7: información
Muestra
Política de operaciones
Política de operaciones de sistemas de información

Número de póliza: XYZ-WI-ISO-001
Versión: 1.0
Departamento: Tecnología de la información
Nombre Posición Firma Fecha
Preparado por: Supervisor de operaciones de TI XX / XX / 20XX

y / o administrador
Revisado por: Director de TI XX / XX / 20XX

Infraestructura
Revisado por: Sistemas de información XX / XX / 20XX

Gerente de Operaciones
Aprobado por: Vicepresidente de TI XX / XX / 20XX
Misión
Promover un entorno e infraestructura de TI que sea confiable y disponible.
Propósito
El propósito de la política de Operaciones de Sistemas de Información es:
◾ Proporcionar una metodología formal en la que las operaciones relacionadas con la información de la organización
Los sistemas de información (SI) están documentados.
◾ Asegurar el funcionamiento eficaz de los sistemas informáticos y los procedimientos programados.
◾ Implementar, ejecutar y hacer cumplir controles y procedimientos para proteger las operaciones de SI.
441
Página 468
442 ◾ Apéndice 7: Ejemplos de sistemas de información
◾ Promover la conciencia entre todos los usuarios de la organización de que los equipos de SI deben protegerse.
en todo momento contra el uso no autorizado, robo, daño físico o daño ambiental.
El equipo de SI consiste en computadoras de escritorio, estaciones de trabajo, servidores, computadoras portátiles y c
ers; redes; dispositivos móviles; unidades externas; Unidades USB; y cintas de respaldo; entre
otros.
Alcance
Esta política cubre los procesos, procedimientos y controles de SI que se implementarán para llevar a cabo
operaciones comerciales al mismo tiempo que se protege el entorno de TI.
Responsabilidades
1. Usuarios:
a. Los usuarios de la organización son totalmente responsables de leer, comprender y cumplir
con todas las políticas y procedimientos descritos en este documento.
2. Supervisores / Administradores:
a. Designados como propietarios de aplicaciones (custodios) de los sistemas de la organización, incluidos
aplicaciones, bases de datos, sistemas operativos y redes.
segundo. Asegurar que los usuarios se adhieran y cumplan estrictamente con las políticas y procedimientos descritos.
dentro de este documento.
C. En relación con el personal de recursos humanos:
yo. autorizar el acceso de los usuarios y ceder la custodia de la información.
ii. revisar el acceso de los usuarios de forma periódica; modificar dicho acceso según sea necesario.
iii. asegurarse de que se proporcione formación a todos los usuarios.
iv. asegurarse de que las políticas y los procedimientos se distribuyan y comuniquen a todos
usuarios.
re. Diseñar e implementar controles y mecanismos de acceso físico para proteger SI específicos
áreas y equipos.
mi. Aprobar horarios, frecuencias y rotaciones de respaldo.
F. Apruebe los resultados de la copia de seguridad y la corrección de las excepciones de la copia de seguridad de man
gramo. Asegurar que las políticas y procedimientos relacionados con las operaciones de SI se revisen y actualicen
en consecuencia.
3. Personal de operaciones de sistemas de información:
a. Cumplir y adherirse estrictamente a todas las políticas y procedimientos descritos en este
documento.
segundo. Recibir de los usuarios (y documentar) notificaciones de fallas identificadas y eventos relacionados
a las operaciones de SI.
C. Diseñe e implemente horarios, frecuencias y rotaciones de respaldo.
re. Ejecutar y monitorear los procedimientos de respaldo.
mi. Comunicar las excepciones señaladas, si las hay, a los supervisores y administradores para que
corrección.
F. Mantenga copias de seguridad actualizadas para todos los datos del sistema y de las aplicaciones.
gramo. Mantenga las copias de seguridad seguras en entornos o ubicaciones adecuadamente controlados.
h. Desarrollar y documentar el plan de continuidad del negocio (BCP) y el plan de recuperación ante desastres.
(DRP). En relación con el personal de seguridad, realice pruebas para ambos planes.
Página 469
Apéndice 7: Ejemplos de sistemas de información ◾ 443
4. Departamento de Recursos Humanos:

a. En relación con el personal de operaciones y seguridad, otorgue, elimine o modifique
acceso, según corresponda, a las instalaciones sensibles de la organización (es decir, centros de datos,
salas, equipos de red y otros edificios / físicos sensibles o relacionados con la informática
áreas que albergan aplicaciones financieras, bases de datos, sistemas operativos y otros
repositorios de información financiera).
5. Gestión:
a. Revise y apruebe las políticas, los procedimientos y las responsabilidades que se indican en este documento.
segundo. Anualmente, revisar, revisar y aprobar BCP y DRP. Revisar y aprobar la prueba
resultados.
C. Promover políticas y procedimientos sólidos que fomenten prácticas comerciales que sean confiables.
su, confiable, efectivo, eficiente, consistente, ético y que cumpla con todos los
leyes y regulaciones.
Política: Directrices de operaciones del sistema de información

Se deben implementar pautas, estrategias y / o mejores prácticas generales para gobernar
Operaciones de SI en la organización. Como lo requiere esta política, la organización debe informar a los usuarios que:
◾ El Departamento de TI es responsable de brindar servicios de SI seguros, precisos y completos a los

organización.
◾ El Departamento de TI mantiene las pautas, políticas y procedimientos necesarios para controlar adecuadamente
controlar las operaciones de SI en la organización.
◾ Las pautas, políticas y procedimientos deben definirse claramente, aprobarse formalmente e implementarse
mento y revisado al menos una vez al año (o cuando sea apropiado) para reflejar los cambios dentro del
entorno de procesamiento.
◾ Las directrices, políticas y procedimientos actualizados deben comunicarse y distribuirse a
todos los usuarios de la organización.
◾ Las actividades de operación de SI deben planificarse y programarse en consecuencia (por ejemplo, diarias, semanales
mensualmente, etc.) de conformidad con las políticas y procedimientos.
◾ Los supervisores o administradores de SI deben garantizar la disponibilidad de todos los suministros necesarios,
software, así como otros equipos y documentación relacionados para que los usuarios ejecuten
sus tareas y deberes.
◾ El mantenimiento de todo el software, hardware y equipo de SI relacionado debe ser
dinado, programado y ejecutado para asegurar un funcionamiento y operación precisos y completos.
◾ Los alimentos, líquidos y similares están prohibidos en el Departamento de TI, el centro de datos y / o cerca
cualquier equipo de SI.
Política: Salvaguardia de los sistemas de información

El equipo de SI y la documentación relacionada deben estar protegidos en todo momento contra
uso, robo, daño físico o daño ambiental. Como lo requiere esta política, la organización
debe informar a los usuarios que:
◾ El equipo IS no debe dejarse sin protección.

◾ Los usuarios deben mantener seguros y protegidos los ID de usuario y las contraseñas. La falta de hacerlo puede result
en una violación de seguridad grave a los datos sensibles y confidenciales de la organización.
Página 470
◾ El equipo de SI no debe usarse ni colocarse en un área física insegura que exponga dicho equipo.
mención a posibles daños físicos.
◾ A menos que se autorice explícitamente, los usuarios no pueden agregar, eliminar ni modificar programas de aplicación
◾ A menos que se autorice explícitamente, los usuarios no pueden quitar dispositivos periféricos o cambiar / eliminar
ajustes de configuración (por ejemplo, ajustes de sonido, apariencia de pantalla, etc.) en cualquier organización
computadora, estación de trabajo, servidor, sistema mainframe, etc.
◾ Para proteger las instalaciones sensibles de la organización, las siguientes condiciones o controles deben ser
implementado:
- Fuentes de alimentación alternativas para evitar el tiempo de inactividad del sistema y bloqueos en caso de que la
falla la fuente de alimentación.
- Sistemas de aire acondicionado alternativos en caso de que falle el sistema de aire acondicionado principal.
- La sala del centro de datos debe colocarse en un lugar seguro con un piso elevado construido
por encima del piso de losa de hormigón original del edificio, dejando un espacio abierto entre los dos
para infraestructura de cableado o refrigeración.
- Sistemas de equipos de extinción de incendios (p. Ej., Sistema de rociadores contra incendios, extinción de incendi
extinción de incendios en aerosol condensado, etc.) que no requieran intervención humana
Ser instalado para controlar y extinguir incendios.
- Gabinetes que almacenan archivos, documentos, medios de respaldo, software y / o cualquier otra información con
la información o el equipo deben estar protegidos y ser resistentes al fuego.
Política: propietarios de aplicaciones designados

Los sistemas de aplicación, incluido el equipo de SI, deben tener al menos un propietario designado. Según sea necesario
según esta política, la organización debe informar a los usuarios que:
◾ El propietario designado, autorizado por supervisores o administradores, es responsable de la

resultados comerciales de su sistema de aplicación, uso comercial y toda la información relacionada.
◾ Los cambios o modificaciones en el sistema de solicitud no se deben realizar sin el consentimiento
del propietario designado.
◾ Los usuarios no designados no deben realizar modificaciones o cambios en los sistemas de aplicación
a menos que esté explícitamente autorizado por (y con el consentimiento de) el propietario designado.
◾ Los propietarios designados para los sistemas de aplicación y su información tienen la autoridad y
responsabilidad de:
- Clasificar la información y su valor.
- Autorizar el acceso a la información a los delegados (custodios).
- Identificar los controles necesarios y comunicar dichos controles a los custodios y / o usuarios de
la información.
- Determinar (y hacer cumplir) los requisitos legales de privacidad y retención de datos.
◾ Los propietarios de aplicaciones designados son responsables de proteger la privacidad y confidencialidad de
la información que posee.
◾ Los formularios apropiados deben estar documentados, completados y autorizados. Los formularios deben incluir
nombres del propietario de la aplicación designado y del sistema de aplicación, así como una descripción de
información relacionada poseída y / o producida. Tanto el propietario designado de la aplicación como el
El supervisor / administrador priado debe firmar el formulario.
Página 471
Política: usuarios de aplicaciones y sistemas

El término usuario se define como todo empleado que utiliza los sistemas de aplicación de la organización y
Equipo IS. Los usuarios están autorizados por los propietarios designados de la aplicación para leer, crear, editar, actualizar,
o eliminar información, según corresponda. Los usuarios son necesarios para salvaguardar la información.
y los sistemas de aplicación utilizados en sus funciones y tareas diarias. Como lo requiere esta política, el
la organización debería exigir a los usuarios que:
◾ Ser responsable del uso adecuado y la protección de todas las aplicaciones de la organización.
sistemas e información.
◾ Utilizar la información solo para el propósito previsto por el propietario de la aplicación designado.
◾ Cumplir con todas las políticas, procedimientos y controles implementados por el aplicante designado
propietario de la
◾ Asegúrese de que la información clasificada, privada o sensible no se divulgue a nadie sin
permiso del propietario de la aplicación designado.
◾ Asegúrese de que las contraseñas individuales no sean divulgadas ni utilizadas por usuarios no autorizados.
Política: seguridad física y acceso a la organización

Instalaciones sensibles
Se han diseñado e implementado reglas, procedimientos y controles específicos para otorgar,
monitorear, modificar y eliminar el acceso físico a las instalaciones sensibles de la organización. Como
requerido por esta política, la organización debe informar a los usuarios que:
◾ El acceso físico otorgado a todas las instalaciones sensibles de la organización debe ser previamente autorizado
rizado, documentado, gestionado y supervisado.
◾ El acceso físico a las instalaciones sensibles de la organización debe restringirse a los usuarios que requieran
dicho acceso para realizar sus funciones laborales. Dicho acceso restringido ayuda a prevenir
Destrucción accidental de equipos de SI e instalaciones sensibles de la organización.
◾ Acceso otorgado al personal de apoyo externo (por ejemplo, vendedores, contratistas, proveedores,
personal técnico, personal de mantenimiento de edificios, etc.) a las instalaciones sensibles de la organización.
debe estar debidamente autorizado y documentado. Dicho acceso concedido debe ser compatible con
propósito y responsabilidades del trabajo.
◾ La concesión de acceso a las instalaciones sensibles de la organización debe seguir la aprobación adecuada de los
visor o administrador.
◾ Un mecanismo de control de acceso físico (por ejemplo, tarjetas de acceso, datos biométricos, cerradura y llave tradici
guardias de seguridad, etc.) se utiliza para restringir y registrar el acceso al edificio y a la organización
instalaciones sensibles de la institución, y la autoridad para cambiar dicho mecanismo se limita a las
personal.
◾ El acceso físico a las instalaciones sensibles de la organización se otorga a través de tarjetas de identificación o datos b
autenticación.
◾ La autenticación biométrica se emplea mediante el reconocimiento de huellas dactilares.
◾ Las tarjetas de identificación no deben ser transferidas ni utilizadas por usuarios no autorizados para eludir
mecanismos y controles de seguridad.
Página 472
◾ Las tarjetas de identificación que ya no se utilicen / sean necesarias deben devolverse inmediatamente al supervisor o
administrador.
◾ Las tarjetas de identificación extraviadas o robadas deben notificarse inmediatamente al supervisor o administrador.
Se aplicarán cargos por todas las tarjetas de identificación perdidas, robadas o no devueltas.
◾ Sey supervisa y registra
dicho registro la entrada
es mantenido de personal
y revisado no autorizadopor
periódicamente a las instalaciones
supervisores sensibles de la organización,
o administradores de TI.
◾ Los visitantes que ingresen a las instalaciones sensibles de la organización deberán registrar su entrada y salida
evidenciar su visita, así como documentar el propósito de dicha visita.
◾ Los visitantes deben ser acompañados por personal autorizado en todo momento.
◾ Los registros de acceso y los registros de visitantes de todas las instalaciones sensibles de la organización deben revisa
de forma periódica. Toda actividad inusual debe ser monitoreada e investigada en consecuencia. Ninguna
Los accesos inusuales identificados deben notificarse y eliminarse de inmediato.
◾ Las revisiones de acceso de usuarios ocurren con frecuencia para respaldar el acceso físico actual otorgado a las organi
instalaciones sensibles.
Política: comunicación de tiempo de inactividad y fallas del sistema

Se instituye un método de notificación para reducir el tiempo de inactividad de los sistemas, interrupciones, fallas de comun
uraciones, fallas de energía, caídas e interrupciones (en conjunto denominadas fallas). Como lo requiere
esta política, la organización debe informar a los usuarios que:
◾ Las fallas de SI identificadas se comunican inmediatamente al personal de operaciones de SI.

◾ Las fallas son registradas y documentadas por el personal de operaciones de SI, y dicha documentación
debe describir:
- condiciones que existían en el momento de la falla
- cualquier actividad inusual observada antes de la falla, y
- posibles soluciones recibidas de gerentes, supervisores, administradores, proveedores,
consultores, etc.
◾ Después de la aprobación apropiada, las correcciones y soluciones se coordinan y se implementan.
◾ Las correcciones y soluciones autorizadas se documentan y se ponen a disposición de los
sonnel. La corrección de fallas está documentada, cerrada y disponible para referencia futura.
Política: procedimientos de respaldo

Se implementan políticas y procedimientos de respaldo para salvaguardar los datos de la organización,
mación, sistemas de aplicaciones y software. Como lo requiere esta política, la organización debe
informar a los usuarios que:
◾ Las copias de seguridad se planifican, se programan de forma coherente y se realizan utilizando

software, herramientas y / o tecnologías de respaldo.
◾ Se guardan copias de los datos, la información, los sistemas de aplicación y el software respaldados
fines de planificación de tinuidad.
◾ En caso de mal funcionamiento, interrupciones o fallas, se debe disponer de una unidad de respaldo alternativa.
capaz, como mínimo, de reemplazar la unidad de respaldo principal.
◾ Los medios de respaldo deben estar debidamente identificados y etiquetados.
◾ Los medios de copia de seguridad deben almacenarse de forma segura y restringirse al personal autorizado. Acceso fís
Deben observarse y cumplirse los controles relacionados con el almacenamiento de copias de seguridad.
Página 473
◾ Antes de realizar copias de seguridad, la información debe clasificarse según el propósito. Para críticos
cal y / o información sensible, se genera un mínimo de dos copias de respaldo (una copia
se entrega a instalaciones de almacenamiento externas; la otra copia se mantiene internamente). Información
que se clasifica como no crítico o no sensible se evalúa, se realiza una copia de seguridad y se almacena fuera del siti
si / cuando sea necesario. Normalmente, es suficiente mantener una copia de este tipo de información.
◾ Las copias de seguridad de información crítica y / o sensible también están protegidas mediante cifrado
métodos.
◾ Se deben ejecutar copias de seguridad completas del sistema antes de realizar cualquier modificación significativa
información relevante o sistema de aplicación.
◾ La frecuencia de las copias de seguridad (es decir, diaria, semanal, mensual, trimestral, semestral y anual) es
establecido en función de cuán sensible y crítica es la información.
◾ La retención de copias de seguridad, que en función de la frecuencia, se establece de la siguiente manera:
- Diariamente: 7 días
- Semanal: 30 días
- Mensual: 90 días
- Trimestral: 365 días
- Semestral: 5 años
- Anualmente: 10 años
◾ El proceso de ejecución de la copia de seguridad se supervisa, registra e incluye una descripción de la información.
copia de seguridad del sistema de aplicación o aplicación.
◾ Las pruebas de restauración de la copia de seguridad se validan y ejecutan. Los resultados se controlan y aprueban.
Política: Plan de continuidad comercial

Un BCP establecido describe los procesos, pasos y procedimientos que se llevarán a cabo en el evento
de una emergencia (p. ej., desastre natural, fallas, interrupciones no planificadas de las actividades comerciales normales
operaciones, etc.) para lograr una recuperación oportuna y disponibilidad de todos los procesos comerciales esenciales,
incluido el IS. Como lo requiere esta política, la organización debe informar a los usuarios que:
◾ La gerencia aprueba el desarrollo del BCP y supervisa su implementación.

◾ El BCP se ha elaborado siguiendo los resultados de análisis y evaluación de riesgos, impactos y costos.
mentos relacionados con pérdidas de información y servicios de SI.
◾ Las prioridades comerciales y las necesidades críticas también se han considerado e incorporado en
BCP.
◾ Se han asignado responsabilidades de personal, según corresponda. Estrategias y procedimientos para
la recuperación ha sido documentada.
◾ El personal de operaciones de SI actualiza y prueba periódicamente el BCP.
◾ Se han establecido y agregado al BCP los criterios de prueba, las condiciones y la frecuencia.
◾ Se evalúan los resultados de las pruebas y se abordan las brechas, debilidades o deficiencias identificadas.
◾ Las pruebas y los resultados de las pruebas se comparten con la gerencia para su revisión y aprobación.
Política: Plan de recuperación ante desastres y pruebas

Un DRP es una herramienta de supervivencia para ayudar a la organización a responder a las amenazas y recuperarse despué
un evento que interrumpe las operaciones comerciales normales. Las pruebas del DRP deben realizarse en un
base periódica para validar los supuestos y actualizar el plan en función de los cambios constantes
Página 474
medio ambiente. Las pruebas también brindan la oportunidad de practicar procedimientos de recuperación e identificar
elementos faltantes. Las pruebas realizadas deben estar disponibles para evaluar los procedimientos técnicos y no técnicos.
Aspectos durales del PRD de la organización. Las pruebas también reducen la posibilidad de errores de comunicación
cuando el plan se implementa durante un desastre real. Además, las pruebas ofrecen a la gestión una oportunidad
sintonía para detectar debilidades y mejorar los procedimientos. Como lo requiere esta política, la organización
debe informar a los usuarios que:
◾ El personal de operaciones y seguridad de TI es responsable de desarrollar, documentar y

probando el DRP.
◾ Los desastres considerados en el DRP incluyen desastres naturales (por ejemplo, terremotos, tsunamis, huracanes).
ricanes, tornados, inundaciones, incendios, etc.) o antinaturales (por ejemplo, ciberataques, interrupción del servicio,
fraude, terrorismo, colapso del mercado, etc.), los cuales crean caos económico y graves
interrupciones comerciales.
◾ El DRP está respaldado y aprobado por la gerencia, y debe abordar los componentes
como:
- Declaración de objetivos y misión
- Servicios y recursos de soporte críticos necesarios para ofrecer productos o servicios.
- Lista de todas las aplicaciones críticas de hardware y software
- Requisitos mínimos de nivel de servicio para información y telecomunicaciones.
- Personal clave y personal mínimo requerido para operar durante el desastre
- Planes de reubicación de empleados a sitios de trabajo alternativos
- Instalaciones de procesamiento alternativas y pasos para transferir los recursos necesarios a dichas instalaciones.
- Copias de seguridad de programas y datos almacenadas fuera del sitio
- Copias de seguridad completas e incrementales de programas y datos
- Se ha designado al presidente y al comité (s) de recuperación ante desastres
- Listas de contactos, números de teléfono de emergencia y sistemas de alerta con pasos a seguir
- Cobertura del seguro
- Pruebas y simulacros
- Documentación de funcionamiento y sistema actualizada
◾ Se deben desarrollar y documentar un plan de prueba, procedimientos y escenarios de prueba apropiados.
coherente con el propósito, las metas y / u objetivos de DRP.
◾ La gerencia debe aprobar un plan de prueba, procedimientos y escenarios de prueba apropiados.
◾ Las pruebas deben realizarse al menos una vez al año.
◾ Las pruebas deben coordinarse y acordarse con ubicaciones alternativas fuera del sitio.
◾ Las pruebas deben incluir la restauración completa de los medios de respaldo y la validación de que los datos siguen si
completa y precisa.
◾ Los resultados de las pruebas deben documentarse y cualquier brecha, debilidad o deficiencia resultante de
esas pruebas deben abordarse y corregirse oportunamente.
Revisión
Versión Descripción de la revisión realizada Interpretado por Fecha
1,00 XX / XX / 20XX
Página 475
Apéndice 8: Auditoría final
Grupos de computación de usuarios
Auditoría de grupos informáticos de usuarios finales

Una vez que se determina que se requiere una auditoría de un grupo de informática de usuario final (EUC), el departamento
El auditor, junto con la gerencia, define los objetivos, la metodología y el alcance y
carpa, antes de preparar el plan de auditoría. Los objetivos de la auditoría pueden cubrir aplicaciones específicas, usuarios fi
apoyo, cuestiones financieras y / o información estratégica que se comunicará a la dirección.
Objetivos de auditoría
Las aplicaciones de PC han pasado de ser personas que crean herramientas de productividad personal a
aplicaciones que utiliza toda la organización. Es posible que la gerencia no se dé cuenta del
importancia de los grupos EUC para la organización para dedicar los recursos necesarios para una completa
y auditoría de aplicaciones exhaustiva. Sin embargo, es esencial contar con el apoyo de la gerencia para
vienen los obstáculos presentados por los grupos EUC. Los usuarios finales tienden a pensar en sus PC como algo personal
propiedad, y pueden estar resentidos por una intrusión de los auditores. Sin embargo, la cooperación del usuario final
se puede obtener, en parte, explicando los objetivos de la auditoría. Un objetivo de auditoría común
Ser para evaluar la eficacia de la aplicación y los controles generales sobre EUC (es decir, Excel crítico
hojas de cálculo, bases de datos de acceso y otras herramientas de informes y análisis de datos). Otros objetivos de una
La auditoría de EUC puede requerir evaluación y pruebas para garantizar que:
◾ Las aplicaciones EUC de la organización se gestionan y almacenan adecuadamente, de acuerdo con

políticas, procedimientos, estándares y orientación internos, para garantizar que sus datos alojados sean o
permanece completo, exacto y válido.
◾ La seguridad se configura, implementa y administra de manera adecuada en todas las aplicaciones EUC.
cationes para proteger contra el acceso no autorizado. Las modificaciones no autorizadas pueden causar
información o su procesamiento sea incompleta, inexacta o inválida.
◾ Información sensible, privada y / o confidencial alojada en el EUC de la organización.
las aplicaciones están adecuadamente protegidas para evitar accesos autorizados, filtraciones de datos y
seguro de que este tipo de información no se verá comprometida o divulgada sin autorización.
Metodología de auditoría
El método utilizado para realizar la auditoría del grupo EUC depende del entorno que se está revisando
y los objetivos de auditoría acordados. Se puede utilizar un inventario de aplicaciones de usuario final para obtener una
449
Página 476
450 ◾ Apéndice 8: Auditoría de grupos informáticos de usuarios finales
comprensión general del grupo EUC. El auditor debe discutir este inventario con la gerencia.
ment para determinar qué tipo de auditoría se debe realizar. Por ejemplo, una auditoría más formal puede
utilizarse si se está evaluando una aplicación específica para determinar su dependencia de la información financiera, mientr
Una auditoría
prácticas de losestadística
usuarios. que
Los recopila
auditoresdatos de muestra
también puedende transacciones
realizar o registros
una evaluación de respaldo
rápida puede
e informal confirmaral personal d
entrevistando
personal sobre sus impresiones del grupo EUC.
Alcance y contenido de la auditoría

La definición del grupo EUC para un entorno particular determinará el alcance y el contenido de la auditoría
la auditoría. El alcance limita la cobertura de la auditoría a un departamento, función o aplicación en particular.
catión. El contenido define qué aspectos de un área en particular se cubren. Según la auditoría
objetivo, el contenido cubre controles generales, controles de aplicación, adquisición de hardware y software
control de desarrollo de sistemas, control de cambios, gestión de problemas o recuperación de desastres.
Plan de auditoria
El plan de auditoría detalla los objetivos, metodologías, alcance y contenido, así como los procedimientos
para cumplir esos objetivos. Como cualquier auditoría, una auditoría de un grupo EUC comienza con un resultado prelimina
vey o análisis del entorno de control mediante la revisión de políticas y procedimientos existentes. Durante
la auditoría, estas políticas y procedimientos deben ser evaluados para el cumplimiento y la eficiencia operativa
eficiencia. La encuesta o análisis preliminar debe identificar la posición y la estrategia de la organización.
para el grupo EUC y las responsabilidades de su gestión y control. La siguiente auditoría
se llevan a cabo procedimientos para reunir la evidencia necesaria sobre la cual basar los hallazgos de auditoría,
clusiones y recomendaciones.
◾ Recopilación de pruebas. Una revisión de cualquier documentación que utilice el grupo de usuarios finales.
◾ Consulta. Realización de entrevistas con usuarios finales y cualquier técnico de soporte de TI.
◾ Observación. Un recorrido para familiarizarse con los procedimientos del departamento y
evaluar los controles.
◾ Inventario. Un examen físico de cualquier bien o producto inventariado disponible en el EUC
grupo.
◾ Confirmación. Una revisión de las encuestas de satisfacción de los usuarios finales que se entregaron y
completado durante las etapas preliminares de planificación de la auditoría.
◾ Procedimientos analíticos. Una revisión de los datos recopilados a partir de información estadística o financiera.
contenidos en hojas de cálculo u otros archivos de datos.
◾ Precisión mecánica. Una revisión de la información contenida en cualquier base de datos utilizada por el
Grupo EUC mediante procedimientos de prueba.
Una vez recopilada la evidencia, el auditor debe evaluar las fortalezas y debilidades del control, considerando
las interrelaciones entre controles compensatorios y superpuestos. Estos controles deben probarse
para el cumplimiento y para asegurar que se apliquen de acuerdo con las políticas y
procedimientos. Por ejemplo, la política de administración puede establecer que los usuarios finales deben cambiar sus contr
periódicamente para proteger los recursos de información. Para probar el cumplimiento, el auditor identifica los controles
que fuerzan los cambios de contraseña. Las pruebas sustantivas determinan la idoneidad de estos controles para prevenir
actividad fraudulenta. Por ejemplo, la piratería de software pone a la empresa en riesgo de recibir multas y
Página 477
Apéndice 8: Auditoría de grupos informáticos de usuarios finales ◾ 451
pérdida de buena voluntad. Revisar los directorios en las unidades LAN y PC en busca de software sin licencia
evaluar la eficacia de los controles para garantizar que solo se instale software con licencia de propiedad.
El plan de auditoría debe abordar la revisión de políticas y procedimientos, asegurar que haya suficientes
y documentación disponible que respalde los procesos y procedimientos de EUC, defina las pruebas de auditoría
realizado y describa el contenido del informe final de auditoría. Estos se describen a continuación.
Políticas y procedimientos de EUC

TI debe tener políticas o pautas que cubran los grupos EUC. Estos deben estar diseñados para proteger
Datos de la compañia. TI también debe tener estándares para garantizar que los usuarios finales no utilicen hardware o
software que no es compatible con ellos. Debe haber una política EUC que abarque y sea
aplicable a todos los grupos EUC. Si solo existen políticas departamentales, cada política debe ser similar a
asegurar la continuidad entre las políticas departamentales. Una política de toda la empresa relacionada con los grupos EUC
debe cubrir:
◾ Cesión de propiedad de los datos

◾ Responsabilidad del usuario
◾ Procedimientos de respaldo
◾ Controles de acceso físico a PC
◾ Documentación adecuada de las solicitudes de todos los grupos EUC y documentación adecuada
cambios y modificaciones
◾ Segregación de funciones
Documentación EUC
Dado que muchos usuarios finales desarrollan sus propias aplicaciones, a menudo hay poca o ninguna documentación.
además de las propias notas del usuario final. Otro problema de auditoría es que varios usuarios finales pueden
desarrollar el mismo tipo de aplicación independientemente unas de otras, lo cual es un uso ineficiente de
recursos informáticos. Por ejemplo, si un usuario final de contabilidad está desarrollando una aplicación que
ya en uso en nómina, debe haber algún tipo de documentación o referencia para que los usuarios finales
consultar para evitar la duplicación de esfuerzos.
Este ejemplo ilustra otro problema planteado por la documentación inadecuada. Un final
El usuario ha desarrollado varias aplicaciones que se han vuelto cruciales para el funcionamiento de la organización.
ción. Esta persona ha dejado la empresa sin dejar ninguna documentación sobre esas solicitudes.
ciones y otros usuarios finales deben utilizar esta aplicación y realizar modificaciones en ella.
Los usuarios finales deben asumir la responsabilidad del mantenimiento de la documentación de sus sistemas.
y aplicaciones, y asegúrese de que sea completo, actual y preciso. El auditor de TI puede realizar
una función de asesoramiento de gestión eficaz al destacar y enfatizar la importancia de EUC
documentación.
Prueba de auditoría de EUC

El auditor debe abordar muchas consideraciones que cubren la naturaleza, oportunidad y extensión de las pruebas.
En g. El auditor debe diseñar un plan de prueba de auditoría y una metodología de prueba para determinar
si los controles previamente identificados son efectivos. El auditor también prueba si el usuario final
las aplicaciones están produciendo información válida y precisa. Para microcomputadoras, varios manuales
y existen métodos automatizados para probar datos erróneos. Un primer paso es navegar por
Página 478
452 ◾ Apéndice 8: Auditoría de grupos informáticos de usuarios finales
directorios de las PC en las que reside la aplicación desarrollada por el usuario final. Cualquier irregularidad en
Los archivos deben investigarse.
Dependiendo de la naturaleza de la auditoría, también se podrían utilizar técnicas asistidas por computadora para
auditar la aplicación. El auditor debe realizar además varias pruebas con valores válidos e inválidos.
datos para probar la capacidad y el alcance de la detección, corrección y prevención de errores dentro de la aplicación
ción. Además, el auditor debe buscar controles tales como balanceo de entrada y registro o hash.
totales para garantizar que el usuario final concilie cualquier diferencia entre entrada y salida. La inten-
La calidad y el alcance de las pruebas deben estar relacionadas con la sensibilidad y la importancia de la aplicación.
El auditor debe tener cuidado con demasiadas pruebas y limitar sus pruebas a controles que cubran todos
las exposiciones clave al riesgo y los posibles tipos de error. La principal preocupación de la auditoría es que las pruebas
revelar cualquier tipo de exposición de datos sensibles y que la información producida por la aplicación
es válido, intacto y correcto.
Informe de auditoría de EUC

El informe de auditoría debe informar a la dirección sobre los resultados de la revisión del grupo EUC. Eso
también puede sugerir apoyo para recursos para mejorar los controles del usuario final. Además, el informe de auditoría
debe recomendar políticas y procedimientos que puedan fortalecer los controles del usuario final. Finalmente, el
El informe de auditoría debe convencer a los usuarios finales y a la dirección de la necesidad de controlar EUC mediante la
tificando la importancia de la información y los activos almacenados en las PC y LAN y señalando
los riesgos de esos activos.
El dictamen del auditor también debe recomendar la administración de los tipos de controles que
necesarios para aumentar la eficiencia y reducir el riesgo y la exposición. Estos controles recomendados deben
definirse de una manera de costo versus beneficio y debe expresarse en términos que la gerencia
Entienda: ¿Cuánto le costará a la empresa si no se implementan estos tipos de controles? o como
¿Cuánto puede ahorrar la empresa si existen dichos controles? Después de que estas recomendaciones hayan sido
hecho, aprobado e implementado, el auditor debe reevaluar los controles para asegurarse de que
han sido implementados y son efectivos.
Página 479
Apéndice 9: Recomendado
Áreas de control para auditoría
Adquisiciones de software
Para compensar los riesgos asociados con la adquisición de software, áreas de control recomendadas, como las
a continuación, deben ser examinados por auditores de TI.
1. Alineación con la estrategia comercial y de TI de la empresa.

2. Definición de los requisitos de información.
3. Estudios de viabilidad (por ejemplo, costos, beneficios, etc.).
4. Identificación de requisitos de funcionalidad, operacionales y de aceptación.
5. Conformidad con las arquitecturas de sistemas e información existentes.
6. Cumplimiento de los requisitos de seguridad y control.
7. Conocimiento de las soluciones disponibles.
8. Comprensión de las metodologías de adquisición e implementación relacionadas.
9. Implicación y aceptación del usuario.
10. Requisitos y viabilidad de los proveedores.
Alineación con la estrategia comercial y de TI de la empresa

Cualquier proyecto de desarrollo de sistemas, ya sea que el sistema lo desarrolle la organización o
perseguido en otros lugares, debe respaldar la estrategia comercial y de TI de la organización. El negocio requiere
Los aspectos asociados con la solución que se busca deben vincularse a las metas y objetivos identificados en
la estrategia comercial y de TI de la empresa. Para obtener más información sobre la alineación de TI con el
negocios, consulte el Capítulo 5.
Definición de los requisitos de información

Los requisitos del sistema y de información deben evaluarse para determinar si están actualizados y
completar. Debido al rápido ritmo del negocio, los requisitos pueden cambiar rápidamente. Por consiguiente,
Los requisitos que se recopilan demasiado antes de la compra real pueden no capturar ningún
cambios en los requisitos comerciales o características técnicas recientemente disponibles.
453
Página 480
454 ◾ Apéndice 9: Áreas de control recomendadas
El mayor desafío al definir los requisitos del sistema es lograr que estén completos.
Los requisitos de un sistema nunca pueden estar completos al 100%. Por el contrario, revisar los requisitos
a lo largo del proceso de adquisición del sistema puede resultar en cambios en el alcance, las expectativas, el costo y
en consecuencia, éxito.
Estudios de viabilidad (por ejemplo, costos, beneficios, etc.)

Los estudios de viabilidad deben revisarse para garantizar que la solución seleccionada no solo cumpla con los
requisitos, sino que también se compara y contrasta con la viabilidad de las otras soluciones.
Los controles y riesgos relacionados se ilustran en los párrafos siguientes utilizando aspectos económicos y técnicos.
viabilidad cal como ejemplos.
La viabilidad económica debe ser revisada y aprobada por un experto
patrocinador antes de la decisión final para garantizar que la pregunta "hacer frente a comprar" sea eficaz
evaluado. La gerencia debe aprobar formalmente el análisis de costo-beneficio. En una circun-
postura, una agencia gubernamental compró una solución de software sin documentación rastreable
de las alternativas revisadas y los costos-beneficios relacionados asociados con cada una. Por consiguiente,
los reguladores examinaron la competencia de la alta dirección y la imparcialidad de la selección
proceso.
Hay varios ejemplos de empresas que preparan estudios de costo-beneficio engañosos que
se basan en beneficios inconmensurables y costos incompletos. Los beneficios a menudo se presentan en términos
de funciones que no se miden en el entorno actual. Como resultado, es difícil probar
Beneficio en el nuevo entorno. Los costos indirectos o en especie a menudo se excluyen de las estimaciones de costos.
Los ejemplos incluyen los costos de personal asociados con la reasignación de personal de sus funciones regulares a
proyecto de implementación. Estos costos pueden incluir honorarios para el personal temporal, pérdida de ingresos asociada
con servicio reducido debido a la reducción de personal, o cambios en la compensación de los empleados como resultado de
mayores responsabilidades laborales o habilidades esperadas.
La viabilidad técnica debe ser revisada y aprobada por un experto e involucrado
patrocinador antes de la decisión final para garantizar la capacidad de la organización para implementar y apoyar el
solución seleccionada. En un ejemplo, el CFO de una empresa compró un paquete ERP financiero sin
consultar previamente a la división de tecnología de la empresa. La división de tecnología se ubicó en
la posición de codificación para incorporar el paquete en la arquitectura existente siguiendo el
compra. En consecuencia, se requirieron cambios en el diseño de la infraestructura técnica que resultaron
realizar compras no planificadas de hardware y software.
Identi cación de Funcionalidad, Operacional y

Requisitos de aceptación
Los requisitos deben extenderse más allá de las expectativas del usuario final. Deben incluir el interno
funcionalidad del sistema teniendo en cuenta los requisitos operativos y de aceptación.
Entre los ejemplos de funciones que se pueden perder se incluyen los requisitos de impresión o
algoritmos específicos para cálculos. En un ejemplo, una empresa tuvo que cambiar inesperadamente su
comprobar el proceso de impresión debido a la implementación de un paquete de software. Porque los cheques fueron
ahora completamente impreso con láser, el cheque impreso tenía que incluir la información de la cuenta en óptica
caracteres, así como el código de barras asociado. La información bancaria del nuevo cheque tenía que ser
Página 481
Apéndice 9: Áreas de control recomendadas ◾ 455
revisado y aprobado por el banco. Además, el tamaño de la fuente tuvo que ajustarse adecuadamente para
la oficina de correos para clasificar sistemáticamente el correo. Finalmente, los cheques se atascaban en el clasificador de co
en la oficina
el papel usadodepara
correos. Debido
imprimir a que el
y enviar el cheque
cheque se
ahora era un
estresó correopor
al pasar adjunto sin un sobre separado,
el pliegue-
ing, el medidor de franqueo y el clasificador de correo. Posteriormente, la empresa compró una
plegadora e implementé otras alternativas para aplicar el franqueo.
Los criterios de aceptación deben ser específicos con medidas detalladas. Los planes de aceptación deben incluir
inspecciones, pruebas funcionales y pruebas de carga de trabajo. Sin pautas de aceptación, el seleccionado
La solución puede no cumplir con los requisitos del usuario, las expectativas de rendimiento o los términos de la
contrato. Hay muchos casos en los que las pautas de aceptación inadecuadas han dado lugar a
interrupciones debidas al funcionamiento inadecuado del sistema o funciones que no funcionan.
Conformidad con las arquitecturas de sistemas e información existentes

Esta área de control se correlaciona directamente con la evaluación de la viabilidad técnica y el negocio
elementos de información. Como se mencionó anteriormente, la conformidad con la arquitectura del sistema existente
es critico. Además, el análisis de viabilidad define las restricciones o limitaciones para el sistema.
tem. La viabilidad debe evaluarse en las siguientes categorías: económica, técnica, operativa,
horario, legal o contractual y político. La viabilidad puede incluir aquellas cosas que son tangibles,
intangible, único o recurrente.
En un caso, una empresa seleccionó un paquete de software que no se adaptaba a los
método para registrar la comisión de sus agentes de ventas en el libro mayor. Por consiguiente,
la empresa optó por modificar la estructura del software para la estructura del plan de cuentas, que
dio lugar a cambios y mantenimiento a la estructura de datos básica del producto, así como a todos los
código y pantallas asociados.
Cumplimiento de los requisitos de seguridad y control

Se necesita una comprensión completa de los requisitos de seguridad y control de la empresa para
asegúrese de que la solución seleccionada sea adecuada. Políticas de seguridad de la empresa y normativa aplicable
lasciones deben revisarse durante el proceso de selección para garantizar que la seguridad y el control
Los requisitos se consideran en el proceso de selección. El responsable de seguridad de la empresa debe
involucrado en la definición de los requisitos de seguridad y control, así como participar en la selección
proceso.
Las adquisiciones e implementaciones de sistemas se vuelven más difíciles cuando estos requisitos son
no bien entendido o documentado. Los resultados se perderán la funcionalidad de seguridad o se perderán
seguridad implementada. En los casos en que la política o los requisitos de seguridad no estén bien documentados
mentado, sería prudente tenerlos documentados y aprobados por la alta dirección antes
el proceso de selección para garantizar que se cumplan los requisitos de seguridad y control.
En situaciones donde existen brechas de seguridad entre los requisitos y la solución evaluada
Se deben evaluar los costos y beneficios de los controles para asegurar que los costos no excedan el
Beneficios Esto brinda una oportunidad para que los riesgos y controles se revisen y actualicen para reflejar
cambios en los negocios y la tecnología. El oficial de seguridad y la gerencia deben participar en
y aprobar cualquier cambio en los requisitos de seguridad o controles seleccionados.
Página 482
456 ◾ Apéndice 9: Áreas de control recomendadas
Conocimiento de las soluciones disponibles

A menudo,
debido los esfuerzosode
al conocimiento desarrollode
experiencia y adquisición de sistemas
los participantes. se centran
Al centrarse en unmás en una final
resultado solución específica.
específico, otros
no se consideran alternativas. Al no considerar otras alternativas, la solución seleccionada puede
aumentar el costo, el alcance o el cronograma del proyecto porque no cumplió con los requisitos básicos,
como la incompatibilidad con la infraestructura actual de la empresa o las prácticas comerciales. Específicamente,
Se necesita tiempo y recursos adicionales para integrar la solución seleccionada en la técnica de la empresa.
infraestructura o prácticas comerciales.
Comprensión de la adquisición relacionada y

Metodologías de implementación
Los métodos de adquisición de una organización pueden ser muy específicos o generales según una variedad de factores.
como las regulaciones gubernamentales. Como ejemplo, las pautas de adquisiciones del gobierno requieren que
Se brindará la oportunidad a todos los proveedores potenciales. En consecuencia, existen requisitos específicos
para publicitar RFPs, evaluar licitadores y adjudicar contratos. Si estas pautas no son
seguidos, los acuerdos pueden no considerarse válidos.
Los métodos de implementación seleccionados pueden no entenderse adecuadamente, y esto puede introducir
riesgo a los plazos, alcance y costos del proyecto. Como ejemplo, una empresa seleccionó un implemento
socio de mentation para ayudarlo a convertir su sistema de facturación heredado en un sistema de vanguardia
utilizando tecnologías de programación recientes. La experiencia y cultura de la empresa se basó en
tecnologías tradicionales de mainframe y la metodología tradicional de desarrollo de sistemas en cascada
gies. El personal estaba mal equipado para comprender (y participar en) los enfoques empleados recientemente
por los socios de implementación seleccionados. La empresa realmente experimentó contratos fallidos con
varios socios de implementación y hubo demandas posteriores presentadas por la empresa y
socios de implementación.
Participación y aceptación del usuario

La participación y aceptación del usuario es fundamental. Sin la participación del usuario, se perderán los requisitos
y no admitirán nuevos sistemas. Existe una mayor conciencia de la importancia del usuario
apoyo y aceptación. Como medio para aumentar el apoyo a los usuarios, muchos proyectos ahora incluyen
gestión de la comunicación y el cambio empresarial como parte de sus planes de proyecto.
La gestión del cambio, en este contexto, incluye personas, organizaciones y cultura. Una cultura
que comparte valores y está abierto al cambio contribuye al éxito. Para facilitar el proceso de cambio,
los usuarios deben participar en el diseño y la implementación del proceso comercial y del sistema.
La formación y el desarrollo profesional también respaldan esto.
El éxito de la implementación del sistema se basa en una comunicación eficaz. Las expectativas deben ser
Comunicado. La comunicación, la educación y las expectativas deben manejarse en todo
la organización. Las aportaciones de los usuarios también deben gestionarse para garantizar que los requisitos,
se obtienen aprobaciones y aprobaciones. La comunicación incluye la promoción formal del proyecto.
equipo, así como el progreso del proyecto a la organización. Los empleados también deben conocer el alcance,
objetivos, actividades y actualizaciones, y la expectativa de cambio por adelantado.
Página 483
Apéndice 9: Áreas de control recomendadas ◾ 457
Requisitos y viabilidad del proveedor

El proceso de adquisición debe garantizar que el proveedor seleccionado cumpla con los requisitos del proveedor.
de la organización como se describe en la propuesta. Como se menciona en el Capítulo 13, estos requisitos
incluir:
◾ Estabilidad de la empresa proveedora

◾ Volatilidad de las actualizaciones del sistema
◾ Base de clientes existente
◾ Capacidad del proveedor para brindar soporte
◾ Software necesario en apoyo del sistema del proveedor
◾ Modificaciones necesarias del software base
Para determinar la viabilidad del proveedor, elementos tales como condición financiera, riesgo de adquisición,
La probabilidad de salir del mercado y la reputación de capacidad de respuesta durante los problemas también deben
ser evaluado.
Página 485
484
Apéndice 10: Glosario
Contabilidad: Proceso de identificar, medir y comunicar información económica sobre

una entidad para decisiones y juicios informados.
Cuenta por cobrar: consulte Cuenta por cobrar.
Precisión: La calidad o estado de ser correcto o preciso.
Servicios actuariales: método mediante el cual las corporaciones definen, evalúan y planifican los
impacto del riesgo. Los actuarios utilizan modelos matemáticos y estadísticos para evaluar el riesgo en el
industrias de seguros y finanzas. La ciencia actuarial se utiliza para evaluar y predecir el futuro.
pagos para seguros y otras industrias financieras como la industria de pensiones.
Asesor: Estar en capacidad de brindar consejos u opiniones. Comités asesores o grupos similares
también tienen la autoridad para emitir una decisión o juicio sobre un tema, además de proporcionar
ing opiniones. Por ejemplo, un comité asesor de una junta directiva puede tener la
capacidad para decidir si ciertas restricciones o regulaciones se están cumpliendo adecuadamente.
Instituto Americano de Contadores Públicos Certificados (AICPA): Representa la profesión de contador público certif
a nivel nacional con respecto a la elaboración de reglas y el establecimiento de normas, y actúa como defensor ant
órganos legislativos, grupos de interés público y otras organizaciones profesionales. El AICPA
desarrolla estándares para auditorías de empresas privadas y otros servicios por CPA; proporciona
materiales de orientación educativa para sus miembros; desarrolla y califica el CPA uniforme
Examen; y supervisa y vela por el cumplimiento de las normas técnicas y
estándares Eticos; entre otras responsabilidades.
Evaluación: Evaluación o estimación de la naturaleza, calidad o capacidad de alguien o algo.
Activos: propiedades y otras cosas de valor propiedad y controladas por una unidad económica o negocio
entidad. Los ejemplos incluyen dinero en efectivo, equipos, derechos de autor, construcción y terrenos.
Garantía: Declaración positiva destinada a dar confianza; una promesa.
Atestiguación o atestación: Dar testimonio de; certificar; declarar ser correcto, verdadero o genuino; declarar
la verdad, en palabras o por escrito, sobre todo afirmar a título oficial.
Auditoría: Examen y evaluación de los estados financieros de una organización. Esto esta hecho
objetivamente, para asegurarse de que los registros sean una representación precisa de la transacción
ciones. Puede ser realizado internamente por los empleados de la organización, o externamente por un
firma auditora externa.
Comité de Auditoría: un comité operativo de la junta directiva de una empresa que está a cargo de
supervisar la información financiera y la divulgación. Todas las empresas estadounidenses que cotizan en bolsa de
mantener un comité de auditoría calificado para cotizar en una bolsa de valores.
Encargo de auditoría: auditoría realizada por el auditor. Más específicamente, se refiere solo a la inicial
Etapa de una auditoría durante la cual el auditor notifica al cliente que ha aceptado la auditoría.
trabajo y aclara su comprensión del propósito y alcance de la auditoría.
Hallazgo de auditoría: consulte Hallazgo.
459
Página 486
460 ◾ Apéndice 10: Glosario
Auditado: Persona o entidad que está siendo auditada.

Auditor: Persona o firma que realiza una auditoría. Consulte Auditoría .
Proceso de auditoría: un proceso de auditoría comienza con una evaluación de riesgos, seguida de un plan de auditoría y un
detalle de los procedimientos a realizar. El proceso finaliza con la documentación y
comunicación de los resultados de la auditoría.
Informe de auditoría: comunicación formal emitida por los auditores que describe los resultados generales de
la auditoría. El informe de auditoría debe incluir (como mínimo) el alcance, los objetivos y
una descripción del tema de auditoría, una descripción de la actividad de trabajo de auditoría realizada, y
conclusiones. Para ser eficaces, los informes de auditoría deben ser oportunos, creíbles, legibles y
un tono constructivo. Ningún elemento es más importante que los demás. Todos trabajan
juntos para proporcionar un informe profesional que sea aceptado y aplicado.
Alcance de la auditoría: consulte Alcance .
Seguimiento de auditoría: seguimiento en papel o electrónico que proporciona un registro paso a paso o un historial docum
transacción. Permite el rastreo de datos hasta su fuente. En términos contables, las pistas de auditoría ayudan
en el seguimiento de datos financieros desde el libro mayor hasta el documento de origen (por ejemplo, factura,
extracto bancario, recibo de comprobante, etc.).
Procesamiento por lotes: tipo de procesamiento de datos que requiere una mínima interacción humana. Eso
es un procesamiento de datos, instrucciones o materiales que no se realiza en tiempo real. Los trabajos de proceso
ejecutar sin ninguna interacción del usuario final o se puede programar para que se inicie por su cuenta como
los recursos lo permiten. El procesamiento por lotes se utiliza para transmitir archivos de gran tamaño o cuando
el tiempo de respuesta no es crítico. Los archivos que se van a transmitir se recopilan durante un período y
luego enviar juntos como un lote.
Benchmarking: proceso de medir la calidad y el desempeño de las políticas de una organización,
productos, programas, estrategias, servicios o procesos frente a los de organizaciones pares
con medidas estándar similares. La evaluación comparativa ayuda a las organizaciones a determinar
cómo otras organizaciones alcanzan sus niveles de alto rendimiento y cómo utilizan esta información
para mejorar su propio desempeño.
Período de bloqueo: un período de al menos tres días hábiles consecutivos, pero no más de 60 días
durante el cual la mayoría de los empleados de una empresa en particular no pueden realizar
alteraciones a sus planes de jubilación o inversión. Un período de apagón generalmente ocurre cuando
se están realizando cambios importantes en un plan. Por ejemplo, el proceso de reemplazar el fondo de un plan
El gerente puede requerir un período de bloqueo para permitir que se lleve a cabo la reestructuración necesaria.
Tecnología Blockchain: libro de contabilidad digital de transacciones económicas que es totalmente público y continuo.
aliado actualizado por innumerables usuarios. Es una lista de registros continuos en bloques. Una cadena de bloqu
La base de datos contiene dos tipos de registros: transacciones y bloques. Los bloques contienen lotes de
actas. Los bloques tienen una marca de tiempo y están vinculados a un bloque anterior. Actas
no puede modificarse retroactivamente.
Junta directiva: grupo de personas que son elegidas o elegidas para actuar como representantes.
de los accionistas para establecer políticas relacionadas con la gestión corporativa y tomar decisiones
siones sobre los principales problemas de la empresa.
Contabilidad: proceso de registro de las transacciones financieras diarias de una empresa, que incluyen
compras, ventas, recibos y pagos por una persona u organización /
corporación. Parte del proceso de contabilidad en los negocios.
Sector de arranque: una región o sector dedicado dentro de un disco duro o cualquier otro dispositivo de almacenamiento d
contiene las instrucciones de código necesarias para "iniciar" un sistema informático.
Continuidad del negocio: un plan de continuidad del negocio (BCP) es un documento formal que describe la
la estrategia, el proceso y los procedimientos de la organización que deben implementarse en el evento
Página 487
Apéndice 10: Glosario ◾ 461
de un desastre. El BCP debe reconocer las amenazas y riesgos que enfrenta la organización, y
Debe
con eldocumentar procedimientos
fin de proteger los activos deespecíficos para prevenir
la organización y recuperarse
y mantener de esasfuncionales.
las operaciones amenazas y riesgos.
Director ejecutivo de auditoría (CAE): ejecutivo independiente de alto nivel responsable de la
auditoría interna. Los CAE tienen un conocimiento integral del negocio y están preocupados
principalmente con las estructuras de control interno de la empresa, incluyendo la efectividad y eficiencia
eficiencia de las operaciones, confiabilidad de los informes financieros y cumplimiento de las leyes pertinentes
y regulaciones.
Director ejecutivo (CEO): ejecutivo, director, líder y / o administrador de mayor nivel
tor en una empresa. Los directores ejecutivos son responsables de gestionar y administrar el
operaciones y recursos de una empresa, incluida la toma de decisiones importantes y significativas.
Las tareas del CEO se enfocan en maximizar el valor (por ejemplo, participación de mercado, precio de las accion
etc.) de la empresa. Los directores ejecutivos informan al consejo de administración de la empresa.
Director financiero (CFO): ejecutivo de alto nivel responsable de la gestión, seguimiento y
seguimiento de las actividades financieras y contables de una empresa. Los directores financieros analizan el
fortalezas y debilidades financieras de pany, evaluar los riesgos financieros y proponer correctivos
comportamiento. Los directores financieros se aseguran de que los informes financieros de la empresa se realicen
completamente. Los directores financieros suelen informar (y ayudar) a los directores ejecutivos con la elaboració
análisis de costo-beneficio, entre otros.
Director de Información (CIO): ejecutivo de alto nivel responsable de la administración, diseño,
e implementación de sistemas informáticos y de TI para beneficiar y apoyar a la organización
metas y objetivos de la nización. Los CIO suelen informar a los CEO, COO o CFO.
Director de seguridad de la información (CISO): ejecutivo de alto nivel responsable del desarrollo y
implementar un programa de seguridad de la información para garantizar los activos de información y la tecnolog
nologías están adecuadamente protegidas. Dicho programa de seguridad debe establecer estrategias, políticas
cias y procedimientos diseñados para proteger las comunicaciones, los sistemas y los activos de la empresa
de amenazas internas y externas. El CISO también puede trabajar junto con el CIO para
adquirir productos y servicios de ciberseguridad y gestionar la recuperación de desastres y los negocios
planes de continuidad. El CISO también suele ser responsable del cumplimiento relacionado con la información.
Director de operaciones (COO): ejecutivo de alto nivel responsable de la gestión diaria,
administración y funcionamiento de la empresa. Es decir, los directores de operaciones se centran en ejecutar
los planes de negocio de la empresa según su modelo de negocio. Los directores de operaciones también se denom
como Vicepresidente Ejecutivo de Operaciones. Los directores de operaciones informan al director ejecutivo y se
segundo al mando dentro de la empresa.
Director de Riesgos (CRO): ejecutivo de alto nivel responsable de identificar, analizar y mitigar
Activar eventos internos y externos que podrían amenazar a una empresa. El CRO trabaja para
asegurarse de que la empresa cumpla con las regulaciones gubernamentales y revise los factores
que podrían afectar negativamente las inversiones o las unidades de negocio de una empresa. El tipo CRO
reporta directamente al CEO.
Director de tecnología (CTO): ejecutivo de alto nivel responsable de la gestión de
necesidades científicas, de investigación y desarrollo y tecnológicas dentro de una organización.
El CTO generalmente informa directamente al CEO.
Dispositivos cliente: un dispositivo cliente se refiere a un programa, computadora de escritorio, estación de trabajo o un usu
capaz de obtener información y aplicaciones de un servidor (conocido como cliente / servidor
relación). Un ejemplo sería un navegador web que solicita información (en forma de
una página web, etc.) de servidores de toda la web. El propio navegador actúa como cliente, mientras que
la computadora que maneja la solicitud y envía la información solicitada es el servidor.
Página 488
Nube (o Cloud Computing): Nube, en términos simples, se refiere a Internet. Computación en la nube
permite almacenar datos y programas y acceder a ellos desde Internet en lugar de la red local
disco duro de la computadora. Este tipo de computación basada en Internet proporciona computadoras compartida
procesar recursos y datos a computadoras y otros dispositivos bajo demanda.
Cumplimiento: Asegúrese de que los asuntos financieros de la organización se manejen de acuerdo con
leyes y reglamentos federales. Se deben implementar procesos de registro, verificación,
e informar el valor de los activos, pasivos, deudas y gastos de una empresa para garantizar
conformidad.
Informática forense: práctica de recopilar, analizar e informar sobre datos digitales de una manera que
es legalmente admisible. Se puede utilizar en la detección y prevención de delitos y en cualquier
disputa donde la evidencia se almacena digitalmente.
Virus informático: consulte la definición de "virus".
Elementos de configuración (CI): unidad estructural fundamental de un sistema de gestión de la configuración.
Los ejemplos de CI incluyen documentos, software, modelos y planes de requisitos individuales.
Consistencia: Conformidad en la aplicación de algo, típicamente lo que es necesario para
en aras de la lógica, la precisión o la justicia.
Procedimiento de control o control: Políticas y procedimientos establecidos para proporcionar una garantía razonable
ance del éxito del control de gestión.
Proceso de control: Dirección de control organizacional que se deriva de las metas y estrategias
planes de la organización.
Riesgo de crédito: El riesgo para el prestamista de que un prestatario no pueda hacer el pago del préstamo requerido.
mentos. El riesgo para el prestamista incluye pérdida de capital e intereses, interrupción de los flujos de efectivo,
y mayores costos de recolección.
Criptografía: método de almacenamiento y transmisión de datos en una forma particular para que solo aquellos
para quien está destinado puede leerlo y procesarlo.
Campañas cibernéticas: serie de operaciones cibernéticas relacionadas realizadas en un entorno de red determinado.
por un solo actor, o como un esfuerzo combinado de múltiples actores. Tales operaciones cibernéticas
por lo general incluyen la planificación y coordinación de ciberataques dirigidos a un único, específico,
objetivo o resultado estratégico.
Ciberseguridad: tecnologías, procesos y prácticas diseñadas para proteger redes, computadoras,
programas y datos de ataques, daños o acceso no autorizado.
Ciberterrorismo: uso de computadoras y tecnología de la información por motivos políticos para causar
trastornos graves o miedo generalizado en la sociedad.
Guerra cibernética: conflicto basado en Internet que implica ataques por motivos políticos a la información y
sistemas de información. Los ataques de ciberguerra pueden deshabilitar sitios web y redes oficiales,
interrumpir o inhabilitar servicios esenciales, robar o alterar datos clasificados y paralizar las finanzas
sistemas, entre otros.
Cartucho de datos: consulte Cartucho de cinta .
Repositorios de datos: consulte un destino designado para el almacenamiento de datos. Específicamente, un repositorio de
historia se refiere a un tipo particular de configuración dentro de una estructura de TI general, como un grupo de
bases de datos, donde una empresa u organización ha optado por mantener varios tipos de datos.
Los repositorios de datos mantienen cierta población de datos aislada para que se puedan extraer para
mayor conocimiento o inteligencia empresarial o para ser utilizado para una necesidad de informes específica.
Deficiencia (o deficiencia de control): existe cuando el diseño u operación de un control no
permitir que la gerencia o los empleados, en el curso normal del desempeño de sus funciones asignadas
ciones, para prevenir o detectar incorrecciones de manera oportuna.
Página 489
Denegación de servicio (o ataque de denegación de servicio o ataque DoS): ataque diseñado para deshabilitar un
red inundándola con tráfico inútil.
Copia de seguridad diferencial: se considera una copia de seguridad parcial. Es una copia de todos los cambios realizados
copia de seguridad completa de los datos. Una copia de seguridad diferencial captura solo los datos que han camb
ences) desde la última copia de seguridad completa , por lo tanto, se completa más rápido y requiere menos medio
para almacenar la copia de seguridad.
Paquetes de disco: componente principal de una unidad de disco duro. Dispositivo de almacenamiento para una computado
una pila de discos magnéticos que se pueden manipular y almacenar como una unidad.
Debido cuidado (o debido cuidado profesional): impone una responsabilidad a cada profesional dentro
una organización de auditores independientes para observar los estándares del trabajo de campo y
informes.
Cifrado: proceso eficaz para lograr la seguridad de los datos mediante la conversión o traducción de datos en un
código secreto, especialmente para evitar el acceso no autorizado. Para leer (o descifrar) un cifrado
archivo, se necesita acceso a una clave secreta o contraseña. Los datos no cifrados se denominan texto sin formato
mientras que los datos cifrados se conocen como texto cifrado.
Riesgo a nivel de entidad: se refiere a un riesgo que puede afectar múltiples ciclos y áreas de estados financieros.
de una entidad.
Examen: una inspección o investigación detallada.
Extender (o extensiones): extender o realizar extensiones en una transacción de factura, para
Por ejemplo, implica verificar que el número de unidades de cada artículo de factura multiplicado por su unidad
el costo se reconcilia con el monto total en dólares de cada artículo. Para ilustrar, si 20 unidades de
El artículo de factura A tiene un costo unitario de $ 10, el costo total del artículo de factura A debe ser
$ 200.
Estándares federales de procesamiento de información (FIPS): estándares anunciados públicamente emitidos por
NIST, después de la aprobación del Secretario de Comercio de conformidad con la Información Federal
Ley de gestión de la seguridad, para uso en sistemas informáticos por parte de gobiernos no militares
agencias y contratistas gubernamentales.
Junta de Normas de Contabilidad Financiera (FASB): Junta privada independiente sin fines de lucro
compuesto por siete profesionales contables independientes) que establecen / mejoran,
y comunicar los estándares de contabilidad e informes financieros en los Estados Unidos.
Los estándares de FASB, conocidos como principios de contabilidad generalmente aceptados (GAAP), gobiernan
la preparación de informes financieros corporativos y son reconocidos como autorizados por el
Comisión de Bolsa y Valores (SEC).
Estados financieros: un registro formal de las actividades financieras y la posición de una empresa,
persona u otra entidad. Los estados financieros de una empresa suelen incluir: Saldo
Hoja, estado de resultados, estado de patrimonio neto y estado de flujos de efectivo.
El balance general se informa en un momento determinado. Los tres restantes financieros
Las declaraciones se preparan y se informan durante un período de tiempo específico.
Hallazgo (o Hallazgo de auditoría): resultado de un proceso que evalúa evidencia de auditoría, como registros,
declaraciones fácticas y otra información verificable relacionada con los criterios de auditoría
se utiliza y lo compara con los criterios de auditoría. Los criterios de auditoría pueden incluir políticas,
procedimientos y requisitos. Los hallazgos de la auditoría pueden mostrar que se están cumpliendo los criterios de
(conformidad) o que no se están cumpliendo (no conformidad). También pueden identificar mejor
prácticas u oportunidades de mejora.
Cortafuegos: parte de un sistema informático o red que está diseñado para bloquear el acceso no autorizado.
al tiempo que permite la comunicación exterior.
Página 490
Footing: se refiere al saldo final al sumar los débitos y créditos en un saldo contable
sábana. Las zapatas se utilizan comúnmente en la contabilidad para determinar los saldos finales que se van a pon
en los estados financieros.
Especialista forense: también conocido como "investigadores de la escena del crimen" o "técnicos en la escena del crimen"
son responsables de recolectar evidencia de la escena del crimen. A veces toman dirección
de los detectives en la escena, pero los oficiales también confían en su juicio y experiencia.
Lenguaje de cuarta generación: también conocido como "4GL" es un lenguaje de programación de computadoras que
asimila el lenguaje humano mejor que otros lenguajes típicos de programación de alto nivel
medidores, como 3GL o 2GL. La mayoría de los 4GL se utilizan para interactuar con bases de datos con consultas
comandos como "BORRAR TODOS LOS REGISTROS DONDE EL APELLIDO ES 'MURPHY'"
o "ENCONTRAR TODOS LOS REGISTROS DONDE EL PRIMER NOMBRE ES 'CHRISTOPHER'".
Fraude: engaño ilícito o criminal con la intención de resultar en beneficios económicos o personales.
Software de detección de fraudes: herramienta diseñada para probar y comparar todo tipo de datos organizacionales
(por ejemplo, financiero, operativo, etc.). El software de detección de fraudes es muy eficaz en la elaboración de p
y monitorear las actividades diarias para buscar patrones en los datos o casos de fraude
actividad prestada, como robo de efectivo, lavado de dinero y empleados que se hacen pasar por proveedores,
entre otros. Herramienta que suelen utilizar los auditores y contables forenses para examinar grandes
volúmenes de datos transaccionales para que puedan detectar y prevenir el fraude corporativo.
Línea directa de fraude: servicio de denuncia de irregularidades confidencial y anónimo para posibles fraudes,
cuestiones éticas y otras preocupaciones.
Copia de seguridad completa del sistema (o copia de seguridad completa): copia completa de todos los archivos y carpe
de los medios (por ejemplo, cinta, disco, CD, DVD, nube, etc.). Normalmente se utilizan copias de seguridad del s
como copia de seguridad inicial o primera seguida de copias de seguridad parciales posteriores.
Requisitos funcionales: los requisitos funcionales especifican algo que el sistema debe hacer
(es decir, una función). Las funciones describen entradas, comportamiento y salidas. Un requisito funcional
Puede ser que un sistema calcule el precio de venta de la factura de un cliente o que agregue
información de contacto del proveedor. Un ejemplo adicional de un requisito funcional podría
ser la generación de informes, digamos un informe de ventas para un período en particular, un costo / beneficio
análisis, etc.
Fuzz Testing: técnica de prueba de software utilizada para descubrir errores de programación y seguridad.
lagunas en un sistema (por ejemplo, sistemas operativos, redes, etc.). Con esta técnica, masiva
Se ingresan cantidades de datos aleatorios en el sistema en un intento de detener el sistema.
de funcionar correctamente.
Puerta de enlace: una puerta de enlace es hardware (es decir, enrutadores o computadoras) que conecta dos redes que utiliz
diferentes protocolos.
Libro mayor: proporciona un registro contable completo, ordenado y resumido de todos los saldos.
transacciones de hoja y cuenta de resultados. Ejemplos de cuentas del libro mayor incluyen
Efectivo, Cuentas por Cobrar, Cuentas por Pagar, Ingresos, Gastos, etc.
Principios de contabilidad generalmente aceptados (GAAP): una colección de cuentas comúnmente seguidas
ing reglas y estándares para la presentación de informes financieros. Las especificaciones GAAP incluyen definic
de conceptos y principios, así como reglas específicas de la industria.
Normas de auditoría generalmente aceptadas (GAAS): conjunto de directrices sistemáticas utilizadas por
tors al realizar auditorías en las finanzas de las empresas, asegurando la precisión, consistencia
y verificabilidad de las acciones e informes de los auditores.
Cuentas genéricas: cuenta de computadora que se comparte o no está vinculada de forma exclusiva a un usuario específico
A efectos de buen control, debería reducirse el uso de cuentas genéricas. Cuentas de usuario
debe ser de propiedad exclusiva para que los usuarios sean responsables de sus propias actividades.
Página 491

Fecha de puesta en marcha
como fue : laLa
diseñado. fecha ende
fecha que se puede
puesta utilizar un sistema
en funcionamiento de aplicaciones
generalmente sigue ainformáticas o está
los resultados listo para
exitosos de lasempe
prue
de la gerencia.
Hash Total: suma un campo numérico no financiero, como el total del campo ordenado por cantidad en
un lote de transacciones de ventas.
Agujero: Debilidad incorporada en un programa o sistema que permite a los programadores ingresar a través de una
puerta ”, sin pasar por los controles de seguridad.
Copia de seguridad incremental: se considera una copia de seguridad parcial. Copia solo elementos de datos que han camb
desde la última operación de copia de seguridad de cualquier tipo (es decir, parcial o total). Desde retroceso increm
Los ups copian cantidades más pequeñas de datos que las copias de seguridad completas, se ejecutan con la frecue
completa más rápido y requiere menos medios para almacenar la copia de seguridad.
Independencia: La independencia del auditor (interno o externo) de las partes que puedan tener
un interés financiero en el negocio que se audita. La independencia requiere integridad y
enfoque objetivo del proceso de auditoría.
Integridad: Ser honesto y directo al tratar y / o comunicarse con los demás.
Control Interno o Estructura de Control Interno: Sistemas y procedimientos diseñados para asegurar
que todos los empleados desempeñen sus funciones con ética y honestidad. Trato de controles contables
específicamente con la integridad de la información financiera interna y la precisión de las
informes oficiales proporcionados a personas externas.
Consejo de Normas Internacionales de Contabilidad (IASB): organismo independiente del sector privado que
desarrolla y aprueba las Normas Internacionales de Información Financiera (NIIF). El IASB
opera bajo la supervisión de la Fundación IFRS. El propósito del IASB es
desarrollar un conjunto único de alta calidad, comprensible, ejecutable y aceptado globalmente
normas de información financiera basadas en principios claramente articulados.
Normas internacionales de información financiera (NIIF): conjunto de normas contables desarrolladas
por el IASB que se está convirtiendo en el estándar global para la preparación de empresas públicas
Estados financieros.
ISO / IEC 27001: Organización Internacional de Normalización Británica (ISO) /
Comisión Electrotécnica Internacional 27001. Un estándar de seguridad conocido
que ayuda a las organizaciones a gestionar la seguridad de activos como la información financiera,
propiedad intelectual, datos de los empleados o información encomendada por terceros. los
La norma ISO / IEC 27001 proporciona requisitos para implementar una seguridad de la información.
sistema de gestión de información sensible de la empresa relacionada, por ejemplo, con el personal
registros, procesos y sistemas informáticos, entre otros.
Control de TI: procedimiento o política que proporciona una garantía razonable de que la tecnología de la información
La tecnología (TI) utilizada por una organización funciona según lo previsto, que los datos son fiables y que
la organización cumple con las leyes y regulaciones aplicables.
Enfoque iterativo: Método que divide el desarrollo de software de aplicaciones en partes.
Cuando se utiliza el enfoque iterativo del desarrollo de software, el código se diseña, se desarrolla
abierto y probado en ciclos repetidos. Con cada ciclo (o iteración), las características adicionales pueden
ser diseñado, desarrollado y probado hasta que exista una aplicación de software completamente funcional
listo para ser implementado en el entorno en vivo.
Programación de trabajos: proceso de asignación de recursos del sistema a muchas tareas diferentes por parte de un operad
sistema de ing. El sistema operativo da prioridad a las colas de trabajos y determina qué trabajo (s)
se ejecutará y la cantidad de tiempo asignada para el trabajo. Programación de trabajos
permite a una organización programar, administrar y monitorear trabajos informáticos (por ejemplo, nómina
programa, etc.).
Página 492

Inventario Just-In-Time: se refiere a una estrategia de inventario o sistema de gestión empleado por
empresas para reducir el tiempo y los costos de inventario al tener inventario disponible para
satisfacer la demanda, pero no hasta un punto en exceso para crear productos adicionales. Se reciben bienes
sólo cuando sean necesarios.
Riesgo de liquidez: el riesgo de que las empresas no puedan cumplir con sus obligaciones financieras a corto plazo.
demandas. El riesgo puede resultar de la incapacidad de convertir un valor o un activo duro en efectivo
sin pérdida de capital y / o ingresos en el proceso.
Malware: código malicioso que se infiltra en una computadora. Es un software intrusivo con el propósito de
Dañar o inutilizar computadoras y sistemas informáticos.
Carta de gestión: una carta de gestión es un documento creado por un auditor que se proporciona para
que identifica hallazgos o áreas / procedimientos que deben mejorarse o rediseñarse (también
denominadas desviaciones, deficiencias de control, excepciones, etc.), como resultado de la auditoría. La carta
también puede incluir los riesgos resultantes de esos hallazgos, así como las recomendaciones del auditor
descripciones que describen un curso de acción por parte de la gerencia de la empresa para restaurar o proporciona
precisión, eficiencia o control adecuado de los sujetos de auditoría. Tanto los riesgos como las recomendaciones
El auditor debe proporcionar las recomendaciones para cada hallazgo de auditoría para que el informe sea útil.
a la Gerencia. Las cartas de administración generalmente no contienen información financiera.
Margen: también conocido como "beneficio bruto". Diferencia entre el precio de venta de un producto o servicio y
su costo de producción.
Riesgo de mercado: también llamado "riesgo sistemático". Riesgo para los inversores de que el valor de sus inversiones
disminuirá (es decir, pérdidas de experiencia) debido a factores que afectan el desempeño general de
los mercados financieros.
Valores negociables: Deudas que se venderán o canjearán dentro de un año. Estos son financieros
instrumentos que se pueden convertir fácilmente en efectivo, como bonos del gobierno,
acciones o certificados de depósito.
Materialidad: el umbral por encima del cual la información faltante o incorrecta en los estados financieros
se considera que tiene un impacto en la toma de decisiones de los usuarios. La materialidad es a veces
interpretado en términos de impacto neto en las ganancias reportadas, o el porcentaje o cambio en dólares
en una partida específica de los estados financieros.
Desviación material: Las incorrecciones materiales se refieren a aquellas incorrecciones (o instancias en las que
una afirmación de los estados financieros no está de acuerdo con los criterios contra los cuales se
auditado; por ejemplo, GAAP) que si están presentes en los estados financieros pueden afectar la
decisiones económicas de los usuarios de dichos estados financieros. Errores de materiales
puede clasificarse como fraude (intencional), otros actos ilegales como el incumplimiento de las leyes
y regulaciones (intencionales o no intencionales), o errores (no intencionales).
Debilidades materiales: una deficiencia, o una combinación de deficiencias, en el control interno sobre
información financiera, de modo que exista una posibilidad razonable de que una incorrección material
de los estados financieros anuales o intermedios de la empresa no se evitarán ni se detectarán
en forma oportuna.
Mole: Un topo ingresa a un sistema a través de una aplicación de software y permite al usuario romper el
procesamiento normal y sale del programa al sistema operativo sin cerrar la sesión
usuario, lo que le da al creador acceso a todo el sistema.
Blanqueo de capitales: ocultación del origen del dinero obtenido ilegalmente, normalmente por medios
de transferencias que involucren a bancos extranjeros o negocios legítimos.
Procesamiento en línea: forma automatizada de ingresar y procesar transacciones (datos, informes, etc.)
en un sistema informático en tiempo real. El escaneo de códigos de barras es un buen ejemplo de
Procesando.
Página 493

Riesgo operacional: Riesgo significa que una empresa se compromete cuando intenta operar dentro de un determinado
campo o industria. El riesgo operacional es el riesgo que no es inherente a un sistema financiero, sistemático o
riesgo de mercado. Es el riesgo que queda después de determinar el financiamiento y el riesgo sistemático,
e incluye riesgos resultantes de fallas en procedimientos internos, personas y sistemas.
Subcontratación: práctica utilizada por distintas empresas para reducir costes transfiriendo partes de
trabajar con proveedores externos en lugar de completarlo internamente. Estrategia eficaz de ahorro de costes
egy cuando se usa correctamente. A veces es más asequible comprar un bien del exterior.
empresas que producirlos internamente.
Período de recuperación: el período de tiempo necesario para que una inversión recupere su desembolso inicial en
términos de beneficios o ahorros.
Prueba de penetración: también conocida como prueba de penetración , es el proceso de intentar obtener acceso a
recursos informáticos (por ejemplo, sistema de aplicación, red, aplicación web, etc.) para encontrar seguridad
debilidades y vulnerabilidades de la ciudad que pueden explotarse. El simulado y autorizado
El ataque replica los tipos de acciones que realizaría un atacante malintencionado para obtener
acceso a las funciones y datos del sistema. Los resultados brindan a las organizaciones una
representación de su puesto de seguridad en un momento dado.
Información de identificación personal (PII): información que se puede utilizar por sí sola o con
otra información para identificar, contactar o localizar a una sola persona, o para identificar a un
vidual en contexto.
Entorno de producción (o entorno vivo): describe el entorno o entorno donde
el software y el hardware reales se instalan para que funcionen según lo previsto al final
usuarios. Un entorno de producción, o un entorno vivo como también se le conoce, es donde el
Se produce la ejecución en tiempo real de los programas de software. Un entorno de producción incluye el
personal, procesos, datos, hardware y software necesarios para realizar las tareas diarias y
operaciones.
Estados financieros pro forma: los estados financieros pro forma se preparan incorporando
ciertos supuestos, proyecciones o condiciones hipotéticas que pueden haber ocurrido o
que puede ocurrir en el futuro. Estas declaraciones se utilizan para presentar una visión de los
resultados a terceros, tal vez como parte de una propuesta de inversión o préstamo. Por ejemplo, un
la corporación podría querer ver los efectos de tres opciones de financiamiento diferentes. Por lo tanto,
prepara balances, estados de resultados y estados de flujos de efectivo proyectados.
Pseudocódigo: notación informal de alto nivel (descripción) utilizada por los programadores para desarrollar
algoritmos.
Junta de Supervisión Contable de Empresas Públicas (PCAOB): una institución corporativa sin fines de lucro
tutelado por el Congreso para supervisar las auditorías de las empresas públicas con el fin de proteger la
intereses de los inversores y promover el interés público en la preparación de información,
informes de auditoría precisos e independientes.
Ransomware: malware (principalmente en forma de ataque de denegación de acceso) que impide que la computadora
los usuarios no tengan acceso a archivos y registros. El ransomware se instala en secreto en un dispositivo
(por ejemplo, computadora, teléfono inteligente, dispositivo portátil) y retiene los datos como rehenes, o
amenaza a la víctima con publicar dichos datos hasta que se pague un rescate. El ransomware simple puede
bloquear el sistema y mostrar un mensaje solicitando el pago para desbloquearlo. Más avanzado
ransomware cifra los archivos o el disco duro de la computadora haciéndolos inaccesibles, y
exige el pago de un rescate a la víctima para poder descifrarlos.
Seguridad razonable: nivel de confianza de que los estados financieros no son
declaró que se espera que un auditor, ejerciendo habilidad y cuidado profesionales, obtenga de
una auditoria.
Página 494

Cuenta por cobrar (o cuenta por cobrar): facturas pendientes que tiene una empresa o el dinero que
la empresa se debe a sus clientes. Se refiere a las cuentas que una empresa tiene derecho a recibir.
porque ha entregado un producto o servicio. Las cuentas por cobrar representan esencialmente una línea de
crédito otorgado por una empresa y pagadero en un período de tiempo relativamente corto, que va desde
unos días a un año.
Fiabilidad: el grado en el que un experimento, prueba o procedimiento de medición produce el mismo
resultados en ensayos repetidos.
Retorno de la inversión (ROI): ROI, generalmente expresado como un porcentaje, mide la ganancia o pérdida
generado en una inversión en relación con la cantidad de dinero invertido. Se usa típicamente
para decisiones financieras personales, para comparar la rentabilidad de una empresa o para comparar
eficiencia de diferentes inversiones.
Riesgo: una situación que expone a peligro, daño o pérdida.
Gestión de riesgos: La previsión y evaluación de riesgos financieros junto con la identificación
de procedimientos para evitar o minimizar su impacto.
Ley Sarbanes-Oxley de 2002 (SOX): Ley aprobada por el Congreso de EE. UU. En 2002 para proteger a los inversores
de la posibilidad de actividades contables fraudulentas por corporaciones. La Ley SOX
exigió reformas estrictas para mejorar las divulgaciones financieras de las corporaciones y prevenir
fraude contable. La Ley SOX fue creada en respuesta a negligencia contable en el
principios de la década de 2000, cuando los escándalos públicos sacudieron la confianza de los inversores en los e
exigió una revisión de los estándares regulatorios. Las disposiciones clave de SOX son la Sección 302
y Sección 404.
Alcance (o alcance de la auditoría): la cantidad de tiempo y documentos que están involucrados en una auditoría, es un
factor importante en toda auditoría. El alcance de la auditoría, en última instancia, establece cuán profundamente
se realiza la auditoría. El alcance de una auditoría puede variar desde simple hasta completo, incluyendo todos
documentos de la empresa.
Comisión de Bolsa y Valores (o SEC): Agencia del gobierno federal de los Estados Unidos
ment. Tiene la responsabilidad principal de hacer cumplir las leyes federales de valores, proponiendo
normas de valores y que regulan la industria de valores, las acciones y opciones de la nación
bolsas, y otras actividades y organizaciones, incluida la comercialización electrónica de valores
kets en los Estados Unidos.
Escepticismo: Dudar sobre la verdad de algo.
Piratería de software: copia, distribución o uso ilegal y no autorizado de software.
Unidad de estado sólido: un dispositivo de almacenamiento electrónico considerado una alternativa a un disco duro. Ellos
son más rápidos que los discos duros y se emplean en muchos productos, incluidos los dispositivos móviles
dispositivos, cámaras, laptops y computadoras de escritorio, entre otros.
Auditorías de código fuente : examen del código fuente en un proyecto de programación (software)
para intentar reducir los errores antes de que el software se lance finalmente a los usuarios.
Las auditorías de código fuente se concentran en descubrir errores, fallas, fallas o fallas en un
programa de software de computadora, así como violaciones de seguridad o violaciones de programación
convenciones.
Spamming: mensajes perturbadores en línea, especialmente mensajes comerciales publicados en una computadora
red o enviado como correo electrónico.
Parte interesada: una persona con un interés o preocupación en algo, especialmente un negocio.
Estrategia: plan de acción o política diseñada para lograr un objetivo principal o general.
Lenguaje de consulta de estructura: lenguaje informático estándar utilizado en la gestión de bases de datos relacionales.
mento y manipulación de datos. El lenguaje de consulta de estructura o SQL se utiliza para consultar, insertar,
actualizar y modificar datos.
Página 495

Subsidiaria: Compañía controlada por un holding.
Libro mayor subsidiario: diseñado para el almacenamiento de tipos específicos de transacciones contables. Un sub-
El libro mayor auxiliar agrupa cuentas similares cuyos saldos combinados equivalen al saldo de una
cuenta específica del libro mayor. Una vez agrupadas las transacciones en el libro mayor auxiliar,
se resumen y se contabilizan en el libro mayor. Información de la dirección general
ger se utiliza para preparar los estados financieros de una empresa.
Prueba sustantiva (o prueba sustantiva): procedimiento de auditoría que examina el estado financiero
mentos y documentación de respaldo para ver si contienen errores. Estas pruebas son necesarias
como evidencia para apoyar la aseveración de que los registros financieros de una entidad están completos,
válido y exacto.
Cartucho de cinta (o cartucho de datos): dispositivo utilizado en unidades de biblioteca de cintas para almacenar datos dig
datos corporativos, archivos de audio / video, etc.) en cinta magnética.
Terrorismo: el uso de la violencia y la intimidación en la búsqueda de fines políticos.
Bomba de tiempo: código que se activa mediante un evento determinado, como una fecha o un comando.
Análisis de tendencias: análisis realizado para identificar patrones en problemas o soluciones. Una común
El propósito del análisis de tendencias es, por ejemplo, intentar predecir el movimiento futuro de un
stock basado en datos anteriores.
Caballo de Troya: Pieza de código dentro de un programa que causa daño al destruir datos u obtener
información.
Validez: El estado o calidad de ser válido (efectivo o legalmente vinculante).
Control de versiones: procedimiento para rastrear y monitorear archivos asociados con una versión. Control de versiones
Los procedimientos también ayudan a coordinar a los programadores que trabajan en varios aspectos o etapas.
del sistema. Hay programas y bases de datos disponibles que pueden almacenar automáticamente
las distintas versiones de archivos.
Virus (o virus informático): pieza de código de programa que contiene lógica de reproducción automática, que
se suma a otros programas y no puede sobrevivir por sí solo.
Vulnerabilidades (o vulnerabilidad): cualidad de ser herido o atacado fácilmente. El estado del ser
abierto a lesiones, o apareciendo como si lo estuvieras.
Enfoque de cascada: modelo de ciclo de vida de desarrollo de sistemas que es lineal y secuencial. los
El enfoque en cascada tiene objetivos distintos para cada fase de desarrollo. Una vez una fase de
se completa el desarrollo, el desarrollo pasa a la siguiente fase (sin girar
espalda).
Delitos de cuello blanco: delitos no violentos motivados financieramente que normalmente implican robar
dinero de una empresa y que normalmente lo hacen los empresarios y los
sionales (ocupando altos cargos dentro de la organización).
Documento de trabajo (o documento de trabajo): colección formal de escritos, documentos, diagramas de flujo,
correspondencia, resultados de las observaciones, planes y resultados de las pruebas, el plan de auditoría, actas
de reuniones, registros computarizados, archivos de datos o resultados de aplicaciones y evaluaciones que
documentar la actividad del auditor durante todo el período de auditoría. Un completo, bien organizado,
Un conjunto de documentos de trabajo legibles y con referencias cruzadas es esencial para respaldar los hallazgos
conclusiones y recomendaciones según se indica en el Informe de auditoría. Normalmente, copia del
El informe de auditoría final se archiva en los papeles de trabajo.
Gusano: código de programa independiente que se replica a sí mismo y devora datos, consume memoria,
y ralentiza el procesamiento.
Página 497
496
Índice
Los números de página seguidos de “e” indican exhibiciones.
UN distribución y retención, 259

controles de entrada, 254-255
Controles de acceso
controles de salida, 258-259
contra usuarios no autorizados, 247 controles de procesamiento, 256–258
seguridad física y, 295-296
Ciclo de vida de desarrollo de aplicaciones, consulte Sistema
gestión de confianza, 333
ciclo de vida del desarrollo (SDLC)
Acceso, Microsoft, 109, 121
Auditorías de TI de aplicaciones, 17
Sistema de información contable (AIS), 162–163
Servicios de aplicaciones, 360
Empleado de cuentas por pagar (A / P), 102e Riesgos del sistema de aplicación, 241–245; consulte también Usuario final
Comité de Estándares Acreditados (ASC) X12 grupo de
desarrollo (EUD), riesgos de aplicación
normas, 251 falla del sistema de comunicaciones, 244
Exactitud e integridad (A&C)
entrada de datos errónea / falsificada, 244
controles de aplicación, 254-255, 256-258, 259 salida inexacta / incompleta, 244–245
ACFE ver Asociación de Examinadores de Fraude Certificados
información inexacta, 243–244
(ACFE) procesamiento incompleto / duplicado / inoportuno, 244
ACL ver Audit Command Language (ACL)
documentación insuficiente, 245
Mantenimiento adaptativo, 212–213
acceso no autorizado a datos, 243
Metodología adaptativa, 183e acceso remoto no autorizado, 243
Desarrollo de software adaptativo (ASWD), 218
seguridad de la información débil, 243
Gestión ágil de proyectos (APM), 181e Apps Run the World, 4, 242, 318
Metodología Agile System Development (ASD),
Metodología ASD, consulte Desarrollo de sistemas ágiles (ASD)
215–218 metodología
AICPA ver Instituto Americano de Público Certificado
ASEC ver Comité Ejecutivo de Assurance Services
Contadores (AICPA) (UN SEGUNDO)
AIPM ver Instituto Australiano de Gestión de Proyectos
Asociación de Examinadores de Fraude Certificados (ACFE), 7
(AIPM) Comité Ejecutivo de Servicios de Aseguramiento (ASEC), 14
AIS ver sistema de información contable (AIS)
ASWD ver Desarrollo de software adaptativo (ASWD)
Instituto Americano de Contadores Públicos Certificados
Función de certificado, 11
(AICPA), 7, 21 ver también Ley Sarbanes-Oxley Auditoría
Comité Ejecutivo de Servicios de Aseguramiento (ASEC), 14
presupuesto, 70, 71–72, 72e
normas de auditoría, 8 control de cambios, 279–281
Guía SAS, 78, 109, 167–168
de centros de datos, 304
SSAE 16, sección AT 801, 366 plazos, 77–78
Instituto Nacional Estadounidense de Normas (ANSI), 251
de DRP, 304–305
ANSI ver Instituto Nacional Estadounidense de Estándares (ANSI) compromiso, 78
Anthem, Inc., 34e
hallazgos, 85–86, 87–89e
APM ver Gestión ágil de proyectos (APM) en seguridad de la información, 336–338
Controles de aplicación, 13, 14e, 119, 253–259, 379, 388
participación en operaciones de SI, 302–305
exactitud e integridad (A&C), 254-255,
fases de, 78e
256-258, 259 plan, 64, 68–78
autenticidad, 254
memorando de planificación, 78
471
Página 498
472 ◾ Índice
Auditoría ( cont. ) documentación y presentaciones, 99
resultados, 85–86 documentos de trabajo electrónicos (EWP), 100
horario, 70 trabajo en grupo, 100
alcance de, 70, 73–77e gestión de recursos, 101
organizaciones de servicios, 365–367 Plan de auditoría, 194-195
adquisiciones de software, 365 sistemas de aplicación, 260–261
equipo, 70, 77–78 Proyectos de SD&I, 224–228
universo, 59–60, 61e Diseño de procedimientos de auditoría, 80–81 ver también Auditoría
Lenguaje de comando de auditoría (ACL), 109, 113 función
como software de auditoría, 115-119 Proceso de auditoría para TI ver Tecnología de la información (TI)
beneficios dentro, 116 proceso de auditoría
procedimientos de mejores prácticas, para probar la contabilidad Programa de auditoria
asientos de diario, 411–415 estudio de caso, 341
comandos, 117–118e para la gestión del control de cambios, 394–395,
reconciliación de datos y formateo para ACL 404–409
pruebas, 411–412 para la seguridad de la información, 392–393, 398–403
características, 116–119 para operaciones de sistemas de información, 391–392,
funciones, 115-116 396–397
análisis de población de entradas de diario, 412 muestra para áreas de TI de control general, 391–409
indicadores potenciales de controles débiles, identificación, Creación de programa de auditoría, 70
412–415 Pistas de auditoría, 213
Comité de Auditoría del Consejo de Administración, 10 Instituto Australiano de Gestión de Proyectos (AIPM),
Función de auditoría, véase también Tecnología de la información (TI); 179–180
Auditoría de tecnología de la información (TI) Autenticidad, 254
creación de programa anual, 70 Estafa de fraude automovilístico, 33e
presupuesto de auditoría, 70, 71–72e Disponibilidad de información, 317–318
encargo de auditoría, 78
conclusiones del auditor, 86
segundo
plan de auditoría, 64, 68–78
proceso de auditoría ver auditoría de tecnología de la información (TI) Copias de seguridad de programas y archivos de datos, 297–299
proceso Banner Security Administrator (BSA), 418, 419
universo de auditoría, 59–60, 61e Comité de Gestión de Riesgos de Basilea, 157
estrategia de comunicación, 86, 90–91 BCP ver plan de continuidad del negocio (BCP)
interno y externo, 10-11 BEC consulte Compromiso de correo electrónico empresarial (BEC)
objetivo y contexto, 68–69 Servicios de evaluación comparativa, 361–362
recomendaciones, 86 Big Data, 6–7, 320, 339e
evaluación de riesgos, 63–64, 65–67e gestión de proyectos, 195-196
papeles de trabajo, 70 Empresas de las "cuatro grandes", 11, 12
Revisión de cuentas "Enfoque de auditoría de caja negra", 121
alrededor y a través del enfoque de la computadora, 121 Apagones, 296
profesión, 7-10 períodos, 38
Auditoría a través de la computadora, 85 Blockchain, 321, 339e
Auditor (es) ver también Auditoría de tecnología de la información (TI); Contabilidad, 36
Herramientas de productividad del auditor Sector de arranque, del disco, 248
controles de aplicación, 119–120 Botnet, 323e
conclusiones y recomendaciones, 86 Traiga su propio dispositivo (BYOD), 6, 319
en gestión de datos, 100 Organización Internacional Británica de Normas para
documentos de trabajo electrónicos (EWP), 100 Estandarización (ISO) / Electro internacional
papel, 19-21, 193-195 Comisión técnica 27002 (ISO / IEC
Normas de independencia del auditor y gobierno corporativo 27002), 136-137
estándares, 37–38 Apagones, 296
Herramientas de productividad del auditor, 97, 98–101 ver también AuditoríaBSA, consulte Banner Security Administrator (BSA)
función; Técnicas de auditoría asistidas por computadora Presupuesto, 150
(CAAT) Errores, 212
planificación y seguimiento de auditorías, 98 Plan de continuidad empresarial (BCP), 92, 213, 299–300
comunicación, 99 Compromiso de correo electrónico empresarial (BEC), delitos en Internet, 33e
gestión de datos, 99–100 BYOD consulte Traiga su propio dispositivo (BYOD)
Página 499
Índice ◾ 473
C Chick-Fil-A, Inc., 34e
Director ejecutivo de auditoría (CAE), 10
CAAT ver Técnicas de auditoría asistidas por computadora (CAAT) Directores ejecutivos (CEO), 10, 18, 134
CAE ver Director Ejecutivo de Auditoría (CAE) Directores financieros, 18
Departamento de Salud Pública de California (CDPH), Director de información (CIO), 18, 68, 134
42–43 Director de seguridad de la información, 163
Instituto Canadiense de Contadores Públicos (CICA), Directores de operaciones, 18
7, 21 Director de riesgos (CRO), 163, 164
Oportunidades profesionales, en auditoría de TI, 26–27 Director de tecnología (CTO), 18, 164
Herramienta de software CASE, consulte Sistemas asistidos por computadoraLey
/ de Protección de la Privacidad Infantil en Línea (COPPA) de
Herramienta de software de ingeniería de software (CASE) 1998, 44, 50e
Empleado de desembolso de efectivo (C / D), 102e CIA ver Agencia Central de Inteligencia (CIA)
Proceso de desembolso de efectivo CICA ver Instituto Canadiense de Contadores Públicos
diagrama de proceso empresarial para, 102e (CICA)
diagrama de flujo para, 103e CIO ver Director de información (CIO)
CCM ver Gestión de control de cambios (CCM) CISA ver Auditor Certificado de Sistemas de Información (CISA)
CDA ver la Ley de Decencia de la Comunicación (CDA) Dispositivos cliente, 243
CDPH ver Departamento de Salud Pública de California Copias de seguridad en la nube, 299
(CDPH) Computación en la nube, 5–6, 319, 339e
Agencia Central de Inteligencia (CIA), 15, 324e Marco de Cloud Security Alliance (CSA), 328
Los directores ejecutivos ven directores ejecutivos (directores generales) COBIT ver Objetivos de control para información y
Centro CERT ver Equipo de preparación para emergencias informáticas Tecnología relacionada (COBIT)
(CERT) Centro Código de Ética Profesional, 24
Certificación, 22 Filtro de comando, 116
Auditor certificado de sistemas de información (CISA), 22 Comité de Organizaciones Patrocinadoras del
Contador Público Autorizado (CPA), 9 Comisión Treadway (COSO), 13, 133,
CFAA ver Ley de abuso y fraude informático (CFAA) 169-170
Sitio web del proyecto CFTT consulte la herramienta informática forense Comunicación
Sitio web del proyecto Testing (CFTT) sistemas de aplicación, 261
Gestión de control de cambios (CCM), 13, 265–282 como herramientas de productividad del auditor, 99
aprobación de cambios, criterios para, 273–274 información y 162–163
puntos de aprobación, 275 Auditoría de TI y, 17, 86, 90–91
participación en la auditoría, 279-281 Participación del auditor de TI en proyectos de SD&I, 232–233
juntas / comités, 272–273 Estrategia de TI, 147
cambiar documentación, 270, 275–276 y cambio organizacional, 279
cambiar el origen y el inicio, 274-275 y recomendaciones, 195, 232–233
Formulario de solicitud de cambio, 267, 268e acceso remoto, 243
gestión de la configuración, 276–277 falla del sistema, 244
controles, 269–270 Ley de Decencia de la Comunicación (CDA) de 1996, 44, 50e
cambios de emergencia, 270 Análisis comparativo, 111, 112e
ejemplo de diagrama de flujo del proceso, 281e Integridad, 255, 256–258, 259
evaluación de impacto, 269 Objetivos de cumplimiento, 158
importancia de, 266 Ley de enmiendas al abuso informático, 39
cambios de mantenimiento, 270–271 Sistemas asistidos por computadora / Ingeniería de software (CASE)
objetivos, para procedimientos, 272 herramienta de software, 203
gestión del cambio organizacional, 277–281 Técnicas de auditoría asistidas por computadora (CAAT), 85,
cultura organizacional, 278–279 98, 336 ver también Función de auditoría; Auditor
política, muestra, 435–439 herramientas de productividad
evaluaciones posteriores a la implementación, 274 para revisiones de aplicaciones, 115–119
procedimientos, 272–276 Lenguaje de comando de auditoría (ACL), 109, 113,
proceso, 127–128, 266–272 115-119
puntos de revisión, 276 para auditar controles de aplicaciones, 119–120
alcance, para procedimientos, 272 partidas de interés de auditoría, 110
distribución de software, 271–272 matemáticas de auditoría, 110
lanzamientos de software, 271 en proceso de auditoría, 109–112
Formulario de solicitud de cambio, 267 para programas de computadora, 122–124e
ejemplo, 268e análisis de datos, 110–112
Página 500
474 ◾ Índice
Técnicas de auditoría asistidas por computadora (CAAT) ( cont. ) Criptografía, 40
controles de base de datos, 120 Gestión de proyectos Crystal Method (CM)
para revisiones operativas, 120–121 metodología, 183e
para muestreo, 113–114 Marco CSA ver Cloud Security Alliance (CSA)
controles de hoja de cálculo, 119 marco de referencia
Fraude asistido por computadora, 8 CSEA ver Ley de mejora de la seguridad cibernética (CSEA)
Delitos informáticos, 32 CSLA ver acuerdo de nivel de servicio al cliente (CSLA)
Estatutos sobre delitos informáticos, 52 CTO ver director de tecnología (CTO)
Centro del equipo de preparación para emergencias informáticas (CERT), Custodios, 331
321 Encuesta de satisfacción del cliente, 361
Informática forense, 21 Acuerdo de nivel de servicio al cliente (CSLA), 356, 357e
herramientas, 125 Servicio de Aduanas, EE. UU., 125
Proyecto de pruebas de herramientas informáticas forenses (CFTT) Ciberataques, 171
Sitio web, 125 realizado en empresas estadounidenses, 34e
Ley de fraude y abuso informáticos (CFAA), de 1984, 39, y ciber violaciones, 47
48e y ciberespionaje, 47
Sistemas de información informática (CIS) ver Información definición, 32
auditoría de tecnología (TI) contra instituciones financieras estadounidenses, 47
Ley de seguridad informática de 1987, 39–40, 48e ver Campañas cibernéticas, 32
también Ley de Seguridad Nacional; Sarbanes– Delitos cibernéticos, 321
Ley Oxley técnicas utilizadas para comprometerse, 322–323e
Virus informáticos, 243, 248, 316, 322e Seguro cibernético, 171
Fraude de confianza / estafa romántica, 33e Ley de mejora de la seguridad cibernética (CSEA), 40
Confidencialidad, 45, 317 Legislación sobre ciberseguridad, 52
Gestión de la configuración, 276–277 Ley de Investigación y Desarrollo de Seguridad Cibernética, 15
Educación continua, para el crecimiento profesional, 22-23 Ciberterrorismo, 32, 47
Desarrollo contratado, 349e Guerra cibernética, 32
Actividades de control, 161–162
Objetivos de control para información y afines
re
Tecnología (COBIT)
gestión de cambios, 269–270 Análisis de datos (DA), 115
Principios marco de COBIT 5, 62e Copias de seguridad de datos, 297–299
marco, 13, 19, 23 Auditorías de centros de datos, 304
estándar de seguridad de la información, 324–325 Procesos de conversión y limpieza de datos, 209–210
Proceso de auditoría de TI, 60, 62–63 Leyes de eliminación de datos, 52
Gobierno de TI, 133-134, 135-136 Protección de archivos de datos, 294
gestión de proyectos, 178 Diagramas de flujo de datos (DFD), 101, 107
para evaluación de riesgos, 165 procedimientos de procesamiento de nómina, 102e
Riesgo de control, 168 Procesamiento de datos, 292–294
COPPA ver Ley de Protección de la Privacidad Infantil en Línea Protección de datos, 52
(COPPA) Repositorios de datos, 244
Violaciones de derechos de autor, 247 DCFL ver Laboratorio de Defensa Informática Forense
Programa corporativo contra la piratería, SIIA, 271 (DCFL)
Fraude empresarial, 316 Plazos, 77–78
COSO ver Comité de Organizaciones Patrocinadoras de Laboratorio de Informática Forense de Defensa (DCFL), 125
la Comisión Treadway (COSO) Infraestructura de información de defensa, 16
Análisis de costo-beneficio, para controles recomendados, 428 Agencia de Sistemas de Información de Defensa, 16
Consejero, auditor de TI como, 19-20 Deloitte, 5-6, 11, 319
Contraterrorismo, 47 Plan abierto de Deltek, 191
CPA ver contador público certificado (CPA) Gestión de la demanda, 149
CPM, consulte Método de ruta crítica (CPM) Denegación de servicio (DoS), 39
Delitos y ciberataques, IT, 31–35 Ataque de denegación de servicio, 300, 322e
Sanciones penales, por violaciones a las leyes de valores, 38 Departamento de Defensa, EE. UU., 16
Metodología Critical Chain / Path (CC / P), 182e Departamento de Salud y Servicios Humanos, EE. UU., 45
Método de ruta crítica (CPM), 190 Departamento de Seguridad Nacional y Apoyo
Factor crítico de éxito, 18 Organizaciones, 15
CRO ver director de riesgos (CRO) Controles de detectives, 162, 293
Página 501
Índice ◾ 475
Fase de desarrollo sistemas incompatibles, 246
tarea de auditor, 226 análisis del sistema incompleto, 247
de SDLC, 203–205 implementaciones ineficaces, 246
DFD ver diagramas de flujo de datos (DFD) destrucción de información por virus informáticos,
Conversión directa / método de transición directa, 209 248–249
Plan de recuperación ante desastres (DRP), 92, 210–211, 300–301 falta de opciones de respaldo y recuperación, 247–248
auditoría de, 304-305 sistemas redundantes, 246
continuidad del negocio y, 311–312 acceso no autorizado a datos, 247
componentes, 301 Satisfacción con el servicio del usuario final, 140–141
Información privilegiada descontento, 323e Arquitectura empresarial, 91–92
Paquetes de discos, 294 Gestión de la movilidad empresarial consulte Dispositivo móvil
Denegación de servicio distribuida, 322e gestión (MDM)
Ataque DoS ver Ataque de denegación de servicio Sistemas de planificación de recursos empresariales (ERP), 4–5, 5e,
DRP ver plan de recuperación ante desastres (DRP) 92, 242, 318
Debido cuidado profesional, 8, 24, 35 ver también Información Marco de gestión de riesgos empresariales (ERM)
auditoría de tecnología (TI) actividades de control, 161–162
Procesamiento de transacciones duplicadas, 244 Modelo COSO-ERM, 157e
definición, 156
identificación de eventos / riesgos, 159
mi
información y comunicación, 162–163
eBay, 278–279 Marco integrado, 157-158
Comisión Económica para Europa, 251 ambiente interno, 158
Análisis de viabilidad económica, 349–350 actividades de seguimiento, 163
EDI ver Intercambio electrónico de datos (EDI) establecimiento de objetivos, 158
Los estándares EDIFACT ver Intercambio electrónico de datos para evaluación de riesgos, 159–160
Administración, Comercio y Transporte respuesta al riesgo, 160–161
(EDIFACT) estándares Diagramas de relación de entidades (ERD), 101
Controles de edición y validación, 255e Controles ambientales, 296–297
EDS ver Sistemas de datos electrónicos (EDS) Equifax, 315
Plan de estudios educativo, auditoría de TI, 24–25 Equity Funding Corporation of America (EFCA),
EFCA ver Equity Funding Corporation of America 7-8
(EFCA) ERD ver diagramas de relación de entidades (ERD)
Ley de Privacidad de Comunicaciones Electrónicas de 1986, Marco ERM, consulte Gestión de riesgos empresariales
43–44, 50e (ERM) Marco
Intercambio electrónico de datos (EDI), 45 Ernst & Young, 7, 11
evaluaciones de auditoría, normas para, 251 Sistemas ERP, consulte Planificación de recursos empresariales (ERP)
riesgos asociados con, 249-251 sistemas
Intercambio electrónico de datos para la administración, Entrada de datos errónea, 244
Comercio y Transporte (EDIFACT) Procedimientos de manejo de errores, 256
normas, 251 Procedimientos de escalada, 213
Procesamiento electrónico de datos (EDP) ver información ESIGN ver Firmas electrónicas en Global y Nacional
auditoría de tecnología (TI) Ley de Comercio (ESIGN)
Sistemas de datos electrónicos (EDS), 363 Normas éticas, asociaciones profesionales y 23-24
Firmas electrónicas en el comercio mundial y nacional Grupos de EUC ver grupos de informática de usuario final (EUC)
Ley (ESIGN), de 2000, 42, 50e EUD ver Desarrollo del usuario final (EUD)
Documentos de trabajo electrónicos (EWP), 100 Gestión del ciclo de proyectos de la Comisión Europea,
Módulo de auditoría integrado, 123e 184e
Cambios de emergencia, 267, 270 Directiva de protección de datos de la Unión Europea de 1995,
EnCase Forensics, 125 53–54e
Cifrado, 243 Identificación de eventos / riesgos, 159
tecnologías, 333 EWPs ver documentos de trabajo electrónicos (EWPs)
Grupos de informática de usuario final (EUC), 302, 449–452 Excel, Microsoft, 109, 121
Desarrollo del usuario final (EUD), 221–222 Enfoque de pérdida esperada, 160
riesgos de aplicación, 245–249 Experian PLC, 34e
ausencia de segregación de funciones, 246–247 Experiencia, en auditoría de TI, 25-26
violaciones de derechos de autor, 247 Función de auditoría externa, 11
mayores costos de organización, 246 Programación extrema (XP), 217–218
Página 502
476 ◾ Índice
F identificación de documento, 104
calidad de la documentación del sistema, 106
Entrada de datos falsificados, 244 utilidad de la evaluación del informe, 107
FASB ver Consejo de Normas de Contabilidad Financiera Ley de Prácticas Corruptas en el Extranjero (FCPA), de 1977, 8, 36
(FASB)
Especialistas forenses, 163
FBI ver Oficina Federal de Investigaciones (FBI) Fraude, 8
FCPA ver Ley de Prácticas Corruptas en el Extranjero (FCPA) Software de detección de fraudes, 163
Análisis de viabilidad, interpretación, 349–350 Línea directa de fraude, 163
Oficina Federal de Investigaciones (FBI), 15, 125 Allanamiento fraudulento, 39
Centro de quejas de delitos en Internet (IC3), 31–32, 33e, FTC ver Comisión Federal de Comercio (FTC)
321 Copia de seguridad completa del sistema, 298, 447
fuentes de amenaza observadas por, 323–324e Requisitos funcionales, 203
Legislación federal sobre integridad financiera, 35–38, 48e Prueba de pelusa, 205
Gobierno federal, EE. UU., 167
Estándares federales de procesamiento de información (FIPS), 166
FIPS 200, 318, 327 GRAMO
Ley Federal de Gestión de Seguridad de la Información GAAP ver Principios de contabilidad generalmente aceptados
(FISMA), de 2002, 41–42, 49e (GAAP)
Manual de auditoría de controles de sistemas de información federal GAAS ver Normas de auditoría generalmente aceptadas
(FISCAM), 106 (GAAS)
Legislación de seguridad federal, 38–42, 48–50e GAIT ver Guías para la evaluación de riesgos de TI (GAIT)
Ley de abuso y fraude informático (CFAA) de 1984, Diagramas de Gantt, 190
39, 48e GAO ver Oficina de Responsabilidad del Gobierno (GAO)
Ley de seguridad informática de 1987, 39–40, 48e GAPPS ver Global Alliance for Project Performance
Firmas Electrónicas en Global y Nacional Estándares (GAPPS)
Ley de Comercio (ESIGN), de 2000, 42, 50e Gartner, Inc., 6–7, 178, 320
Ley Federal de Gestión de Seguridad de la Información GAS ver Normas de contabilidad del gobierno (GAS)
(FISMA), de 2002, 41–42, 49e Controles informáticos generales, 12-13, 14e, 253, 379,
Ley de Seguridad Nacional de 2002, 40, 49e 381–387
Estándares de seguridad de datos de la industria de tarjetas de pago Software de auditoría generalizada, 85, 115
(PCI DSS), de 2004, 41, 49e Principios de contabilidad generalmente aceptados (GAAP), 9,
Ley Uniforme de Transacciones Electrónicas (UETA), de 37
1999, 42, 50e Normas de auditoría generalmente aceptadas (GAAS), 9
Comisión Federal de Comercio (FTC), 44 Cuentas genéricas, 254
Filtros, global y comando, 116 Git, 271
Consejo de Normas de Contabilidad Financiera (FASB), 9 Alianza global para estándares de desempeño de proyectos
Aplicaciones financieras, identificación de, 80–81 (ESPACIOS), 180
Auditoría financiera, 9 a 10 Filtro global, 116
Gestión financiera, proceso de gobernanza, 150 Cuadrícula de información global, 16
FIPS consulte los estándares federales de procesamiento de información Fechas de lanzamiento, 205
(FIPS) Oficina de Responsabilidad del Gobierno (GAO), 11, 106, 160,
FISCAM consulte Controles de sistemas de información federales 167
Manual de auditoría (FISCAM) Normas de contabilidad del gobierno (GAS), 167
FISMA ver Administración Federal de Seguridad de la Información Estafa de suplantación de identidad del gobierno por correo electrónico, 33e
Ley (FISMA) Ley Gramm-Leach-Bliley de 1999, 46, 51e
Técnicas de diagrama de flujo ver también Productividad del auditor Software colectivo / colaborativo, 100
herramientas; Técnicas de auditoría asistidas por computadora Estándares globales GS1 EDI, 251
(CAAT) Guías para la evaluación de riesgos de TI (GAIT), 169
aplicaciones procesan datos, 104
idoneidad de, 107–108
como herramienta de análisis de auditoría, 103–107
H
diagrama de flujo de datos de auditoría, 104, 106 Hackers, 323e
símbolos comunes, 105e Hacktivismo, 323e
evaluación de control, 106–107 Totales hash, 257
eficacia del procesamiento de datos, 107 Tecnología de la información sanitaria para fines económicos y
definir elementos de datos individuales, 106 Ley de Salud Clínica (HITECH), de 2009,
desarrollar diagramas de flujo, 106 45–46, 51e
Página 503
Índice ◾ 477
Ley de Responsabilidad y Portabilidad del Seguro de Salud participación en la auditoría, 336–338
(HIPAA) de 1996, 16, 44–45, 51e programa de auditoría (estudio de caso), 341 véase también Auditoría
Estándares internacionales Health Level-7 (HL7), 251 programa
Servicio de asistencia técnica, 211–212 herramientas de auditoría y mejores prácticas, 338, 339e
Fundación Heritage, 47 computación en la nube, 319
Método de gestión de proyectos HERMES, 183e COBIT, 324–325
HIPAA consulte Portabilidad de seguro médico y controles, 332–334
Ley de responsabilidad (HIPAA) sistemas de planificación de recursos empresariales (ERP), 318
Histogramas, 110-111 gestión de identidad, 333–334
ejemplo de, 111e gestión de incidentes, 334
Ley HITECH, consulte Tecnología de la información sanitaria para requisitos de designación de clasificación de información,
Salud económica y clínica (HITECH) 330
Actuar responsabilidades del custodio de la información, 331
Agujeros, 248 responsabilidades del propietario de la información, 331
Ley de Seguridad Nacional de 2002, 40, 49e ver también ISO / IEC 27002, 325–327
Ley de seguridad informática; Sarbanes-Oxley en el entorno de TI, 318–321
Servicios de HRM ver Gestión de recursos humanos (HRM) gestión de dispositivos móviles (MDM), 319–320
servicios NIST, 327–328
Servicios de gestión de recursos humanos (HRM), 362 otras tecnologías que impactan en los entornos de TI,
320–321
política, 328–330
yo
roles y responsabilidades, 330–331
IA ver Aseguramiento de la información (IA) selección y prueba de ISC, 334–335
IASB ver Consejo de Normas Internacionales de Contabilidad responsabilidades de terceros, 331
(IASB) gestión de amenazas, 333
IBM, 363 amenazas y riesgos, 321–324
IBS ver Cuadro de mando integral de TI (IBS) gestión de confianza, 333
IDEA ver Extracción y análisis de datos interactivos responsabilidades del usuario, 331
(IDEA) gestión de vulnerabilidades, 332
Gestión de identidades, 333–334 Sistemas de información (SI), 8, 11
Estándar IEEE 1490-2011, 180 auditoría ver auditoría de tecnología de la información (TI)
IFAC ver Federación Internacional de Contadores (IFAC) versus tecnología de la información, 12e
IFRS ver Normas Internacionales de Información Financiera Directrices para la seguridad de SI, 14
(NIIF) Operaciones de sistemas de información (SI), 13, 291–310
OIG ver Información generada por la organización (OIG) participación en la auditoría, 302-305
IIA ver Instituto de Auditores Internos (IIA) herramientas de auditoría, 305, 306–309e
Fase de implementación plan de continuidad empresarial (BCP), 299–300
tarea de auditor, 227 copias de seguridad en la nube, 299
procesos de conversión y limpieza de datos, 209–210 auditorías de centros de datos, 304
Plan de desastres de TI, 210–211 protección de archivos de datos, 294
de SDLC, 208–212 procesamiento de datos, 292–294
apoyo, 211–212 Plan de recuperación ante desastres (DRP), 300–301, 304–305
documentación del sistema, 211 grupos de informática de usuario final (EUC), auditoría, 302
formación, 211 controles ambientales, 296–297
Los informes IMTEC ver Gestión de la información y política y procedimientos operativos, 292
Informes de tecnología (IMTEC) controles de acceso y seguridad física, 295–296
Gestión de incidentes, 334 política, muestra, 441–448
Procesamiento de transacciones incompletas, 244 copias de seguridad de programas y datos, 297–299
Copias de seguridad incrementales / diferenciales, 298 muestra de lista de verificación de auditoría, 306–309e
Información, 317 Tecnología de la información (TI), 3 ver también Legislación
y comunicación, 162–163 relevante para la tecnología de la información; ESO
Garantía de la información (IA), 15–16 Cuadro de mando integral (IBS); Planificación de TI
Información generada por la organización (OIG), 376 memorándum
Gestión y tecnología de la información (IMTEC) componente, 11
informes, 167 controles, 7
Instalación de procesamiento de información, auditoría de, 92 delitos y ciberataques, 31–35
Seguridad de la información (ISec), 13, 317–318 sistemas de información versus, 12e
Página 504
478 ◾ Índice
Tecnología de la información (TI) ( cont. ) instalación de procesamiento de información, 92
Plan de desastres de TI, 210–211 otros tipos de auditorías de TI, 91–92
ejemplo de evaluación de riesgos utilizando NIST SP 800-30, revisión preliminar, 78–80
417–434 evaluación de riesgos, 63–64, 65–67e
Auditoría de tecnología de la información (TI), 11 a 13 pruebas sustantivas, 83, 85
papel del auditor, 19-21 resumen de, 91e
oportunidades profesionales, 26-27 y desarrollo de sistemas, 92
certificación, 22 controles de prueba, 81–83, 84e
cuerpo común de conocimientos, 21-22 Entorno de tecnología de la información (TI), 3 a 7
y protocolos de comunicaciones, 17 controles de aplicación, 388
educación continua, 22-23 enfoque de auditoría, 121
currículo educativo, 24-25 computación en la nube, 5-6
apoyo del gobierno, 27 controles, 379
agrupaciones de, 12-13, 14e documentar aplicaciones relevantes, 380
garantía de la información, 15–16 planificación de recursos empresariales (ERP), 4–5
Auditor de TI como consejero, 19-20 controles generales de computadora, 381–387
Auditor de TI como investigador, 20-21 información general sobre, 79–80
Auditor de TI como socio de la alta dirección, 20 seguridad de la información en, 318–321
Perfil de auditor de TI, 25-26 gestión de dispositivos móviles (MDM), 6
Implementación del programa de gobierno de TI, 18-19 otra información, 388–389
consultoría de gestión, 26-27 otros sistemas que impactan, 6–7
metodologías de, 15 como parte de la estrategia de la organización, 7
necesidad de, 16-17 políticas y procedimientos en operaciones de SI, 292
industria privada, 26 riesgos, 379
asociaciones profesionales y normas éticas, riesgos manejados por seguros, 170
23-24 comprensión, 374, 379–389
profesión de 21-25 Gobernanza de la tecnología de la información (TI)
contabilidad pública, 26 alineación con los objetivos comerciales, 134-135
razones para, 18e COBIT, 135-136
organizaciones de servicios, 365–367 marcos, 135-137
adquisiciones de software, 365 Marco ISO / IEC 27002, 136-137
tendencias, 13-15 Cuadro de mando integral de TI (IBS), 139–144
Auditor de tecnología de la información (TI) Biblioteca de infraestructura de TI (ITIL), 135
como consejero, 19-20 Métricas de rendimiento de TI, 137–144
resumen de las leyes de privacidad internacionales relevantes para, marco conjunto, 137
53–54e ejecución del programa, 18-19
como investigador, 20-21 cumplimiento normativo y controles internos,
participación en sistemas de aplicación, 259–261 144-145
participación en proyectos de SD&I, 223–233 Biblioteca de infraestructura de tecnología de la información (ITIL)
perfil (experiencia y habilidades), 25-26 marco, 135, 270, 328
papel de, 19-21 Métricas de rendimiento de la tecnología de la información (TI),
como socio de la alta dirección, 20 137-144
tarea, 225–228 satisfacción del servicio del usuario final, 140–141
Resumen de las leyes federales de EE. UU. Relevantes para, 48–51e orientación futura, 140
Proceso de auditoría de tecnología de la información (TI) Cuadro de mando integral de TI (IBS), 139–141
hallazgos de auditoría, 85–86 Valor empresarial generado por TI, 139–140
plan de auditoría, 64, 68–78 perspectiva de eficiencia y efectividad operativa,
universo de auditoría, 59–60, 61e 140
Auditoría BCP, 92 pasos en la construcción de IBS, 141–144
comunicación, 86, 90–91 Comité Directivo de Tecnología de la Información, 146–147
sistemas y aplicaciones informatizados, 92 Estrategia de tecnología de la información (TI), 145–146
Objetivos de control para información y afines comunicación, 147
Tecnología (COBIT), 60, 62–63 gestión de la demanda, 149
procedimientos de auditoría de diseño, 80–81 gestión financiera, 150
documentar los resultados, 85–86 Comité Directivo de TI, 146–147
Auditorías de DRP, 92 planificación operativa, 148–150
arquitectura empresarial, 91–92 gestión de adquisiciones y proveedores, 150
Página 505
Índice ◾ 479
inicio de proyecto, 149 Cuadro de mando integral de TI (IBS)
revisión técnica, 149 satisfacción del servicio del usuario final, 140–141
Servicios de infraestructura, 360 ejemplo de, 142-144e
Instituto de Auditores Internos (IIA), 7, 10, 21, 169 orientación futura, 140
Informe de control y auditoría de sistemas, 14 Valor empresarial generado por TI, 139–140
Seguro Métricas de rendimiento de TI, 139–141
cibernético, 171 perspectiva de eficiencia y efectividad operativa,
como evaluaciones de riesgos de TI, 170-172 140
Instalaciones de prueba integradas, 122e pasos en la construcción de IBS, 141–144
Integridad y eficiencia en la capacitación en auditoría informática ITED ver Director Ejecutivo de TI (ITED)
plan de estudios, 14 Entorno de TI, consulte Tecnología de la información (TI)
Integridad de la información, 317 medio ambiente
Traspaso destructivo intencional, 39 Director ejecutivo de TI (ITED), 418–419
Extracción y análisis de datos interactivos (IDEA), 109 ITGC (controles generales de TI), 17
Foro Intergubernamental de Auditoría, 10 Gobierno de TI ver Tecnología de la información (TI)
Función de auditoría interna, 10 a 11 gobernancia
Supervisor de auditoría interna, 25 Marco ITIL ver Tecnología de la información
Entorno interno, 158 Marco de la biblioteca de infraestructura (ITIL)
Consejo de Normas Internacionales de Contabilidad (IASB), 9, 10 Métricas de rendimiento de TI, consulte Tecnología de la información (TI)
Corporación Internacional de Datos, 5, 319 métricas de rendimiento
Federación Internacional de Contadores (IFAC), 13 Memorando de planificación de TI
Normas Internacionales de Información Financiera (NIIF), evaluación de deficiencias, 376
9-10 horas y costos, 374
Organización Internacional de Normalización (ISO) información generada por la organización, 376
17799 y 27000, 14 Equipo de auditoría de TI, 374
Leyes internacionales de privacidad, 52 Controles y riesgos de TI, 375
resumen, 53–54e nota, 373
Asociación Internacional de Gestión de Proyectos (IPMA), otras áreas de asistencia de auditoría de TI, 377
180 planificación de discusiones, 373
Internet propósito, 373
delitos, 33e controles de aplicación relevantes, 375
usos para, 31 aplicaciones y elementos tecnológicos relevantes,
Centro de quejas de delitos en Internet (IC3), FBI, 31–32, 374–375
33e controles de organización de servicios, evaluación, 376–377
Sistemas de Internet de las cosas (IoT), 6, 320, 339e calendario del trabajo de auditoría de TI, 374
Proveedores de servicios de Internet (ISP), 40 comprensión del entorno de TI, 374
Estafa de intimidación / extorsión, 33e trabajo de otros, 376
Investigador, auditor de TI como, 20-21 Estrategia de TI ver estrategia de tecnología de la información (TI)
Los sistemas de IoT ven sistemas de Internet de las cosas (IoT)
IPMA ver Asociación Internacional de Gestión de Proyectos
J
(IPMA)
IS ver Sistemas de información (SI) JAD ver Desarrollo de aplicaciones conjuntas (JAD)
ISACA (Auditoría y Control de Sistemas de Información Programación de trabajos, 293
Asociación), 5, 7, 21, 23, 168–169, 338 Desarrollo de aplicaciones conjuntas (JAD), 218–219
ISec ver seguridad de la información (ISec) Muestreo de juicio, 113
Orientación ISO 10006: 2003, 180
ISO 21500: orientación 2012, 180
K
Norma de gestión de servicios de TI ISO / IEC 20000, 269
Norma ISO / IEC 27000, 165–166 Kanban, como tipo de metodología ágil, 217
Norma ISO / IEC 27002, 136–137, 325–327 Kodak, 363
Norma ISO / IEC 27005: 2011, 165 KPMG, 11
Los ISP consulte Proveedores de servicios de Internet (ISP)
TI ver Tecnología de la información (TI)
L
Auditoría de TI ver Auditoría de tecnología de la información (TI)
Auditor de TI ver Auditor de tecnología de la información (TI) Ley de Protección de Datos Personales en Posesión de Particulares
Proceso de auditoría de TI ver Auditoría de tecnología de la información (TI) Partes de 2010, México, 53e
proceso Desarrollo de software ajustado (LSD), 220–221
Página 506
480 ◾ Índice
Análisis de viabilidad legal y contractual, 350 Excel, 109, 121

Legislación relevante para la tecnología de la información Proyecto de Microsoft, 191
reglas de independencia del auditor, 37–38 Gestión de dispositivos móviles (MDM), 6, 319–320
Ley de protección de la privacidad infantil en línea (COPPA) Modelo de plan de estudios, en educación en auditoría de SI y TI, 24
de 1998, 44, 50e Técnica de modelado, 111
Ley de Decencia de la Comunicación (CDA) de 1996, 44, Método de conversión modular, consulte Conversión por fases
50e método
Ley de fraude y abuso informáticos (CFAA), de 1984, Lunares, 248
39, 48e Blanqueo de capitales, 47
Ley de seguridad informática de 1987, 39–40, 48e Actividades de seguimiento, 163
sanciones penales por violaciones a las leyes de valores, 38
Ley de Privacidad de Comunicaciones Electrónicas de 1986,
norte
43–44, 50e
Firmas Electrónicas en Global y Nacional NA ver administrador de red (NA)
Ley de Comercio (ESIGN), de 2000, 42, 50e Instituto Nacional de Justicia (NIJ), 125
legislación federal sobre integridad financiera, 35–38, 48e Instituto Nacional de Estándares y Tecnología (NIST)
Ley Federal de Gestión de Seguridad de la Información computación en la nube, 5, 319
(FISMA), de 2002, 41–42, 49e Ley de seguridad informática de 1987, 40
legislación de seguridad federal, 38–42, 48–50e estándar de seguridad de la información, 327–328
Ley Gramm-Leach-Bliley de 1999, 46, 51e Base de datos nacional de vulnerabilidad, 324
Tecnología de la información sanitaria para fines económicos y evaluación de riesgos, 64, 166–167
Ley de salud clínica (HITECH) de 2009, SCM, 276
45–46, 51e guía de seguridad para el cumplimiento de HIPAA, 16
Ley de Responsabilidad y Portabilidad del Seguro de Salud Publicación especial (SP) 800-30, 156, 166-167,
(HIPAA) de 1996, 44–45, 51e 417–434
Ley de Seguridad Nacional de 2002, 40, 49e herramientas de apoyo, 160
leyes internacionales de privacidad, 52 Agencia de Seguridad Nacional (NSA), 15, 16
Ciberataques y delitos informáticos, 31–35 Estrategia nacional para proteger el ciberespacio, EE. UU., 14, 15
Estándares de seguridad de datos de la industria de tarjetas de pago Administrador de red (NA), 418
(PCI DSS), de 2004, 41, 49e NIJ ver Instituto Nacional de Justicia (NIJ)
Ley de Privacidad de 1974, 43, 50e NIST consulte el Instituto Nacional de Estándares y
legislación sobre privacidad, 42–47, 50–51e Tecnología (NIST)
Junta de Supervisión Contable de Empresas Públicas Cambios no rutinarios, 267
(PCAOB), 36 NSA ver Agencia de Seguridad Nacional (NSA)
Ley Sarbanes-Oxley (SOX) de 2002, 35–38, 48e
leyes estatales, 47, 52
O
Ley Uniforme de Transacciones Electrónicas (UETA), de
1999, 42, 50e Los estándares ODETTE ver Organización para el intercambio de datos
USA PATRIOT Act de 2001, 46–47, 51e según los estándares de Tele Transmission (ODETTE)
Leyes federales de EE. UU. Relevantes para los auditores de TI, 48–51eDeslocalización, 364 véase también Subcontratación
Determinación de probabilidad, 420–421 Producto estándar, 348e
LSD ver Desarrollo de software ajustado (LSD) OLA ver acuerdo de nivel operativo (OLA)
Proyecto de seguridad de aplicaciones web abiertas (OWASP)
Directrices de codificación segura, 205, 252–253
METRO
Acuerdo de nivel operativo (OLA), 356, 357e
Mantenimiento de sistemas, 212–213 Proceso de planificación operativa, 148–150
tarea de auditor, 227 Análisis de viabilidad operativa, 350
Software malicioso, 322e Controles de seguridad operacional, 428
ataques, 248, 316 Fase de operaciones y mantenimiento
Prácticas de consultoría de gestión, 26-27 tarea de auditor, 227
Carta de gestión, 82, 86 de SDLC, 212–214
ejemplo de auditoría de TI, 90e Supervisor de operaciones (SO), 418–419
Controles de seguridad de gestión, 426 Gestión del cambio organizativo, 277–281
Error material, 80 Cultura organizacional, definida, 278–279
MDM consulte Gestión de dispositivos móviles (MDM) Auditorías organizativas de TI, 17
Microsoft Organización para el intercambio de datos por teletransmisión
Acceso, 109, 121 (ODETTE) estándares, 251
Página 507
Índice ◾ 481
OS ver Supervisor de operaciones (OS) Fase de revisión preliminar, del compromiso de auditoría de TI,
Controles de salida, 293–294 78–80
Subcontratación Controles preventivos, 162, 293
de otra organización, 349e PricewaterhouseCoopers, 11
Sistemas de TI, 362–365 PRiSM ver Proyectos que integran métodos sostenibles
desarrollo tecnológico, 15 (Prisma)
Pautas de codificación segura de OWASP ver Open Web Ley de Privacidad de 1974, 43, 50e
Proyecto de seguridad de aplicaciones (OWASP) Secure Legislación sobre privacidad, 42–47, 50–51e
Directrices de codificación Ley de protección de la privacidad infantil en línea (COPPA)
de 1998, 44, 50e
Ley de Decencia de la Comunicación (CDA) de 1996, 44,
PAGS
50e
Método de conversión en paralelo, 210 Ley de Privacidad de Comunicaciones Electrónicas de 1986,
Simulación en paralelo, 123e 43–44, 50e
Socio, director o director (PPD), 70, 77 Ley Gramm-Leach-Bliley de 1999, 46, 51e
Período de amortización, 140 Tecnología de la información sanitaria para fines económicos y
Estándares de seguridad de datos de la industria de tarjetas de pago (PCI Ley de salud clínica (HITECH) de 2009,
DSS) marco, 16, 41, 49e, 328 45–46, 51e
Oficinas de servicios de nómina (PSB), 362 Ley de Responsabilidad y Portabilidad del Seguro de Salud
PCAOB ver Supervisión contable de empresas públicas (HIPAA) de 1996, 44–45, 51e
Junta (PCAOB) Ley de Privacidad de 1974, 43, 50e
PCI DSS ver Seguridad de datos de la industria de tarjetas de pago USA PATRIOT Act de 2001, 46–47, 51e
Estándares (PCI DSS) Industria privada, auditores de TI, 26
Pruebas de penetración, 205 Entorno de producción, 266
PEO ver Organizaciones profesionales de empleadores (PEO) Asociaciones profesionales y normas éticas, 23-24
Mantenimiento perfecto, 213 Organizaciones profesionales de empleadores (PEO), 362
Protección de información personal y electrónica Estado financiero proforma , 111
Ley de Documentos de 2000 (PIPEDA), Canadá, Copias de seguridad de programas y datos, 297–299
53e Técnica de evaluación y revisión del programa (PERT)
Información de identificación personal (PII), 32 metodología de gestión de proyectos, 183e, 190
PERT ver Técnica de evaluación y revisión del programa Gestión de programas, 192–193
(IMPERTINENTE) Módulo de auditoría programado, 123e
Técnica de pharming, 322e Gestión del ciclo de proyectos, 184e
Método de conversión por fases, 209–210 Gestión de proyectos, 177–179
Estafa de phishing, 322e papel del auditor en, 193-195
Controles de acceso y seguridad física, 295–296 plan de auditoría, 194-195
PII consulte Información de identificación personal (PII) big data, 195-196
Método de conversión piloto, 209 certificación, 191-192
PIPEDA consulte Protección de información personal y comunicación y recomendaciones, 195
Ley de documentos electrónicos de 2000 empleo de herramientas de gestión, 190-191
(PIPEDA) factores clave, 184-191
Fase de planificación, de SDLC, 202-203 metodologías, 180, 181–184e
PMBOK ver Cuerpo de conocimientos sobre gestión de proyectos supervisión y seguimiento (O&T), 188, 188–190e
(PMBOK) planificación, 184, 185–187e
PMI ver Project Management Institute (PMI) gestión de programas, 192–193
PMLC ver ciclo de vida de la gestión de proyectos (PMLC) gestión de recursos, 188
PMO ver Oficina de gestión de proyectos (PMO) evaluación de riesgos, 193-194
Certificación PMP ver Project Management Professional normas y orientación, 179–184
(PMP) Certificación Cuerpo de conocimientos sobre gestión de proyectos (PMBOK),
Política, seguridad de la información, 328–330 179, 192
Análisis de viabilidad política, 350 Instituto de Gestión de Proyectos (PMI), 179, 180
Gestión de carteras, programas y proyectos (PPPM) Ciclo de vida de la gestión de proyectos (PMLC), 178
metodología, 182e Oficina de gestión de proyectos (PMO), 178–179
Sobretensiones, 296 Certificación de Project Management Professional (PMP),
PPD vea Socio, director o director (PPD) 177, 191-192
Metodología PPPM ver Portafolio, Programa y Proyecto Proyectos EN Ambientes Controlados (PRINCE2), 182e
Metodología de gestión (PPPM) Proyectos que integran métodos sostenibles (PRiSM), 183e
Página 508
482 ◾ Índice
Creación de prototipos y desarrollo rápido de aplicaciones técnicas, 161e

(RAD), 219–220 ROI consulte Retorno de la inversión (ROI)
PSB ver Oficinas de servicios de nómina (PSB) Cambios de rutina, 267
Empresas de contabilidad pública, auditores de TI, 26
Junta de Supervisión Contable de Empresas Públicas
S
(PCAOB), 8, 36
Paquete de proveedor comprado, 348e SA ver Administrador de sistemas (SA)
Ley de puerto seguro de 1998, 54e
Muestreo, CAAT para 113–114
R
Gestión de auditoría de SAP, 109
Muestreo de atributos aleatorios, 113 Ley Sarbanes – Oxley (SOX) de 2002, 8, 17, 35–38, 48e,
Ransomware, 33e, 248, 316 269, 133, 145 ver también American Institute
Fraude inmobiliario, 33e de Contadores Públicos Autorizados (AICPA);
Cuentas a cobrar y valores negociables, 8 Ley de seguridad informática; Seguridad nacional
Trasgresión imprudente y destructiva, 39 Actuar
Fiabilidad, 138 SAS ver Declaración sobre estándares de auditoría (SAS)
Solicitud de información (RFI), 351e Técnica SCARF ver Archivo de revisión de auditoría de control de sistemas
Solicitud de propuesta (RFP), 351–352e (BUFANDA) técnica
Recopilación de requisitos, 203 SCM, consulte Gestión de configuración de software (SCM)
Riesgo residual, 432 Enfoque de puntuación, 160
Gestión de recursos, 188 Scrum (marco de desarrollo de software), 216–217
Retorno de la inversión (ROI), 140 SDLC ver Ciclo de vida de desarrollo del sistema (SDLC)
RFI ver Solicitud de información (RFI) SEC ver Comisión de Bolsa y Seguridad (SEC)
RFP ver Solicitud de propuesta (RFP) Sección 302: Responsabilidad corporativa de finanzas
Análisis de riesgos, realización, 350 Informes, 37
Evaluaciones de riesgos, 163–164 Sección 404: Evaluación de gestión de internos
sistemas de aplicación, 260 Controles, 37
en función de auditoría, 63–64 Ley de la Comisión de Bolsa y Valores (SEC) de
planificación y seguimiento de auditorías, 98 1934, 8
COBIT para, 165 Violaciones de las leyes de valores, sanciones penales para, 38
seguro cibernético, 171 Comisión de Bolsa y Seguridad (SEC), 35, 38
gestión de riesgos empresariales, 159–160 Arquitectura de seguridad, 317
ejemplo para el área de auditoría funcional de TI, 65–67e Leyes sobre violaciones de seguridad, 51–52
orientación en, 164-167 SEI ver Instituto de Ingeniería de Software (SEI)
seguros como, 170-172 Autoseguro, 172
ISO / IEC 27000 para 165–166 Acuerdos de nivel de servicio (SLA), 354, 356
Riesgos de TI normalmente asegurados, 170-171 tipos de, 357–358e
NIST para 166–167 Gestión De Servicios
NIST SP 800-30 proceso cíclico, 363e
análisis de control, 420 servicios de TI definidos, 355–356
recomendaciones de control, 425–432 acuerdos de nivel de servicio (SLA), 356, 357–358e
análisis de impacto, 421 mediciones de servicio, para rastrear el desempeño,
determinación de probabilidad, 420–421 359–362
documentación de resultados, 432–434 modelo de servicio / precio, 356, 358
determinación del nivel de riesgo, 421–425 participación y prestación de servicios, 358–359
caracterización del sistema, 417–419 herramientas, 361–362
identificación de amenazas, 419 Organizaciones de servicios, auditoría, 365–367
identificación de vulnerabilidad, 420 SIIA ver Asociación de la industria de software e información
del proceso de desarrollo de proyectos, 193-194 (SIIA)
reducción y retención de riesgos, 171-172 Escepticismo, 8
Proyectos SD&I, 224 SLA ver Acuerdos de nivel de servicio (SLA)
Gestión de riesgos, 155-156 Habilidades blandas, 26
definición, 156 Asociación de la Industria de Software e Información (SIIA),
Marco ERM, consulte Gestión de riesgos empresariales 271
(ERM) Marco Adquisiciones de software, áreas de control recomendadas para
Reducción del riesgo, 171-172 auditoría, 453–457
Respuesta al riesgo, 160–161 Gestión de configuración de software (SCM), 276
Página 509
Índice ◾ 483
Contratos y licencias de software, 353–354 Adquisición de sistemas

Instituto de Ingeniería de Software (SEI), 205 plan de aceptación, 355
Piratería de software, 247 auditoría, 365
Versiones de software, implementación de 271 estudio de caso, 369
Unidades de estado sólido, 248 completar la aceptación final, 355
Sony Pictures Entertainment Inc., 35e análisis de viabilidad, realización, 349–350
Auditorías de código fuente, 205 identificación de alternativas, 347–349
SOX ver Ley Sarbanes-Oxley (SOX) opciones, 348–349e
Técnica de spam, 322e proceso, 346–355
Spoofing, 322e ver también virus informáticos; Software malicioso adquisición de software, 353–354
Software espía, 322e análisis de riesgo, realización, 350
Staples, Inc., 34e proceso de selección, 350–352
Leyes estatales, 47, 51–52 estrategia, 346
Declaración sobre normas de auditoría (SAS), AICPA, 78, requisitos del sistema, definición, 346–347
109, 167–168 Administrador de sistemas (SA), 419
Leyes estatales de privacidad en las redes sociales, 52 Técnica de archivo de revisión de auditoría de control de sistemas (SCARF),
Técnicas de muestreo estadístico, 113, 114e 124e
Análisis estructurado, 203 Ciclo de vida de desarrollo de sistemas (SDLC), 181e
Programa de lenguaje de consulta de estructura, 256 Sistemas que intercambian información comercial electrónica,
Libro mayor subsidiario, 259 riesgos para, 249-251
Pruebas de auditoría sustantiva, 83, 85 Eventos de prueba del sistema, 207–208e
Proceso de selección de proveedores, 351–352e
Acuerdos de nivel de servicio con proveedores, 356, 358e T
Sueco, Joseph, 34e
Análisis y requisitos del sistema Cartuchos de cinta, 294
tarea de auditor, 225–226 Target Corporation, 35e
de SDLC, 203 Hojas de tareas, 191
Fase de diseño del sistema TCM ver Marco de gestión de costes totales (TCM)
tarea de auditor, 226 Análisis de viabilidad técnica, 350
de SDLC, 203 Auditorías técnicas de TI, 17
Ciclo de vida de desarrollo del sistema (SDLC), 201–214 Controles técnicos de seguridad, 426
Desarrollo de software adaptativo (ASWD), 218 Fraude de soporte técnico, 33e
riesgos y controles adicionales, 214–215 Fraude telefónico, 39
Desarrollo de sistemas ágiles (ASD), 215–218 Terrorismo, 47
enfoques, 215–222 Terroristas, 324e
tarea de auditor, 225–228 Fase de controles de prueba, de auditoría, 81–83, 84e
comunicación, 232–233 Datos de prueba, 122e
desarrollo, 203-205 Fase de prueba
desarrollo del usuario final (EUD), 221–222 tarea de auditor, 226-227
implementación, 208–212 de SDLC, 205–208
Participación del auditor de TI, 223–233 Amenazas, seguridad de la información
Desarrollo de aplicaciones conjuntas (JAD), 218–219 identificación, 419
Desarrollo de software ajustado (LSD), 220–221 gestión, 333
operaciones y mantenimiento, 212–214 y riesgos, 321–324
fases, 202e Bombas de tiempo, 248
planificación, 202-203 Marco de gestión de costos totales (TCM), 183e
Creación de prototipos y desarrollo rápido de aplicaciones Estándar de Tradacoms, 251
(RAD), 219–220 Metodología tradicional ver metodología Waterfall
evaluación de riesgos, 224 Capacitación, implementación de proyectos, 211
muestra de lista de verificación de auditoría, 228–232e Etiquetado de transacciones, 124e
análisis y requisitos del sistema, 203 Treadway, James C., Jr., 169-170
diseño de sistema, 203 Tesorero, 102e
pruebas, 205–208 Análisis de tendencias, 212
desarrollo del sistema de cascada, 215, 216e Caballo de Troya, 248, 322e
Documentación del sistema, 211, 213–214 Gestión de fideicomisos, 333
sistemas de aplicación, 101–102 Principios y criterios de los servicios de confianza (TSPC), 14
técnicas, 98 TSPC ver Principios y criterios de servicios de confianza (TSPC)
Página 510
484 ◾ Índice
U Estándares VDA ver Verband der Automobilindustrie

(VDA) estándares
UAT ver pruebas de aceptación del usuario (UAT) Normas de Verband der Automobilindustrie (VDA),
UETA ver Ley Uniforme de Transacciones Electrónicas (UETA) 251
Ley Uniforme de Transacciones Electrónicas (UETA), de 1999, Verizon, 34e
42, 50e Sistema de control de versiones (VCS), 271
Riesgos no asegurables, 172 Software de videoconferencia, 99
Equipo de suministro de energía ininterrumpida (UPS), Violaciones de las leyes de valores, sanciones penales para, 38
296–297 Virus, computadora, 243, 248, 316, 322e
Estados Unidos (EE. UU.) Vulnerabilidades, 15
Equipo de preparación para emergencias informáticas (US-Cert), identificación, 420
204, 252 gestión, 332
Servicio de Aduanas, 125
Departamento de Defensa, 16
W
Departamento de Salud y Servicios Humanos, 45
Instituto Nacional de Justicia del Departamento de Justicia Vigilantes del gasto del Congreso, 11
(NIJ), 125 Metodología de cascada
gobierno federal, 167 gestión de proyectos, 181e
resumen de leyes federales, 48–51e desarrollo de sistemas, 215, 216e
Oficina de Responsabilidad del Gobierno (GAO), 11, 106, Seguridad de la información débil, 243
160, 167 Riesgos de las aplicaciones web, 252–253
Estrategia nacional para asegurar el ciberespacio, 14, 15 WhatsApp Inc., 34e
Procesamiento inoportuno, 244 "Enfoque de auditoría de caja blanca", 121
Equipo UPS, consulte Sistema de alimentación ininterrumpida (UPS) Crimen de cuello blanco, 316
equipo Worms, 248, 322e ver también Virus informáticos
USA PATRIOT Act de 2001, 46–47, 51e
Prueba de aceptación del usuario (UAT), 206e
X
Interfaz de usuario, 254
Asistencia al usuario, 211–212 Xerox Corporation, 363
XP ver Programación extrema (XP)
V
Y
Validez, 138
Técnica de muestreo variable, 113-114 Y2K, 213
VCS ver Sistema de control de versiones (VCS) Yahoo !, 34e

Control y Auditoría de Tecnologías de La Información

Cargado por

Información del documento

Título original

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

Control y Auditoría de Tecnologías de La Información

Cargado por

Copyright:

Formatos disponibles

Página 1

© 2019 por Taylor & Francis Group, LLC

Sin reclamo de obras originales del gobierno de EE.

Impreso en papel sin ácido

Libro estándar internacional número-13: 978-1-4987-5228-2 (tapa dura)

Visite el sitio web de Taylor & Francis en

y el sitio web de CRC Press en

Le dedico este libro a mi esposa, Ghia, mi hija Elizabeth y mi

Prefacio ................................................. .................................................. ................................. xvii

SECCIÓN I FUNDAMENTOS PARA LA AUDITORÍA DE TI

Empresas de Contaduría Pública ............................................... .............................................. 26

2 Legislación relevante para las tecnologías de la información ............................................ ........... 31

3 El proceso de auditoría de TI ............................................. .................................................. ... 59

Programa de auditoría ................................................ .................................................. .......... 70

4 Herramientas y técnicas utilizadas en la auditoría de TI .......................................... ...................... 97

CAAT para muestreo ............................................... .................................................. ..... 113

SECCIÓN II PLANIFICACIÓN Y ORGANIZACIÓN

Conclusión ................................................. .................................................. ................... 150

6 Gestión de riesgos ............................................... .................................................. .... 155

7 Gestión de proyectos ............................................... .................................................. 177

Plan de auditoría ................................................ .................................................. ................ 194

8 Ciclo de vida del desarrollo del sistema ............................................. .................................. 201

SECCIÓN III AUDITORÍA DEL MEDIO AMBIENTE

10 Gestión de control de cambios .............................................. .................................... 265

11 Operaciones de sistemas de información .............................................. ................................ 291

Conclusión ................................................. .................................................. .................. 305

12 Seguridad de la información ............................................... ................................................. 315

13 Adquisición de sistemas, gestión de servicios y subcontratación ................................. 345

Completando la aceptación final ............................................... ..................................... 355

Apéndice 1: Memorando de planificación de TI ............................................ ........................................... 373

Apéndice 2: Comprensión del entorno de TI ........................................... .................. 379

Apéndice 5: Ejemplo de evaluación de riesgos de TI con NIST SP 800-30 ................................... 417

Apéndice 7: Ejemplo de política de operaciones de sistemas de información .......................................... .441

Apéndice 8: Auditoría de grupos informáticos de usuarios finales ......................................... ............... 449

Apéndice 10: Glosario .............................................. .................................................. ...... 459

Índice ................................................. .................................................. .............................. 471

Nuevo en la quinta edición

◾ Diapositivas de presentación de PowerPoint significativamente mejoradas, con información adicional relevante

Organización y contenido del capítulo

Sección I — Fundamentos de la auditoría de TI (cuatro capítulos)

El compromiso de auditoría de TI y la importancia de la documentación de auditoría de TI al respaldar

Sección II — Planificación y organización (cuatro capítulos)

El capítulo 5 reconoce la globalización existente de muchas industrias y mercados financieros,

Sección III — Auditoría del entorno de TI (cinco capítulos)

Objetivos clave de aprendizaje

4 ◾ Control y auditoría de tecnologías de la información

◾ La tecnología ha mejorado la capacidad de capturar, almacenar, analizar y procesar enormes

Planificación de recursos empresariales (ERP)

Entorno de tecnología de la información y auditoría de TI ◾ 5

Figura 1.1 Sistema modular de planificación de recursos empresariales.

6 ◾ Control y auditoría de tecnologías de la información

totalmente cómodo al almacenar su información y aplicaciones en sistemas que residen fuera de

Gestión de dispositivos móviles (MDM)

◾ integrarse bien dentro de la organización y se implementan para cumplir con la organización

Otros sistemas tecnológicos que afectan el entorno de TI

Entorno de tecnología de la información y auditoría de TI ◾ 7

técnicas y tecnologías para permitir la captura, almacenamiento, distribución, gestión y análisis

Entorno de TI como parte de la estrategia de la organización

8 ◾ Control y auditoría de tecnologías de la información

Entorno de tecnología de la información y auditoría de TI ◾ 9

10 ◾ Control y auditoría de tecnologías de la información

Funciones de auditoría interna versus externa

Función de auditoría interna