You are on page 1of 195
Done s DOM AUDITORIA INFORMATICA OBJETIVOS DE CONTROL CONTROLES EN UN ENTORNO INFORMATIZADO: OBJETIVOS, DIRECTIVAS Y__ PROCEDIMIENTOS DE AUDITORIA. BELDEN MENKUS, CISA, CSP EDITOR ZELLA G. RUTHBERG, CSP ASSISTANT EDITOR Traduccién Autorizada y Exclusiva en Espanol, por Manuel Palco, CISA. THE EDP AUDITORS FOUNDATION, INC. Carol Stream, Illinois, Estados Unidos. THE INFORMATION SYSTEMS CONTROL FOUNDATION. La Informacion contenida en esta publicacion pretende refiejar una concepcion del aisono. to too, operacion, mantenimiento. y auctor. de ‘sistemas de informacion -tanfo en und Sonfiguracion convencional centralzada cuanto 6h tt ‘entomno informatico de los denominados Gehiguidos. Clertas practicas y procedimientos ‘contenidos en esta publicacion pueden no ser Gpiicables a todos os sstemas de proceso de Gatos. En consecuencia, elincumplimiento de alguna practica o procedimiento especfico contenido ef. festa publicacion no debiera ser utlizado pare Imputar a [a direccion un fallo en el uso de 1a ‘prudencia o de la precaucion en el cumpiimiento de ‘sus obligaciones. La EDP Auditors Foundation es una corporacion no lucrative ‘de beneficios mutuos de Califomia, con Gapituios en todo el mundo. Su proposito y objetive ‘dedicarse a la formacién e Investigacion en SReampo de la Audttoria de Sistemas de Informacion. ‘Se entlende que nila EDP Auditors Foundation See vutores estén prestando aqui servicio legal, contabee O| ‘profesional alguno y en consecuencla: Mychazan expicttamente cualquier responsabilidad Tesutonte del segumiento de cuclesauiera do oeprounaciones. practicas 0 procedimiantos contenidos en ‘esta publicaci6n. Esta publicacién no ‘Sina en consideracion ningun requisito legal o ‘gubemamental que afecte a las practices de ‘Guditoria y 110s controles en los diversos pases. Esta publicocion se prepar6 bajo la direccion de Jos siguientes miembros de Ia Junta de Io EDPAA/EDPAF de 1.989-1.990: International President John A. Kuyers, CPA, CISA, CSP Ernst & Young Executive Vice-President Deepak Sarup, ACA Deloitte Ross Tohmatsu Intemational ‘Administrative Vice-Presdent ‘Amold Dito, CISA Fireman's Fund Insurance Co. Vice-President of Research Michael Donahue. CISA, CSP Price Waterhouse. peconocemes también con agradecimiento la osstencla de Joann Menkus en la correccion y aoe mposicion hniciales y ia de Steven Arbitman por agiizar los ‘artes finales de este documento. ©Copyright, 1990 porlG EDP Auditors Founddation Inc. Coro! stream linols Estados Unidos) Reservodos Reerfederechos. Ninguna parte de esta publicocion puede ser reproducida en forma alguna sin el permiso escrito de la Fundacion. © Copyright, 1990 del original en inglés: EDPAF. Traduceién ol castellano por Manuel Palao, CISA. vice-Presidente de la Organizacion de Auditora: Moc S ica, Capitulo Espanol de la EDPAF: bajo permiso de ¥ mediante acuerdo con Ia EDPAF, estore del ofginal inglés, y que retiene todos sus derechos © Copyright, 1991. de Ia traduccién al castellano: Manuel Palao. Esta traducci6n ha sido supervsada por Miguel Angel Ramos, CISA miembro del ‘Comité Directivo y exPresidente de la Organizacion de Audttorig informética, Capitulo Espanol de Ia EDPAF. y por eSooy s: Wnobrey. Traductora e Intérprate cartiicada Por Os ‘Tilbunales Federales de los EEUU: y ha Fe00y vga 0 consulta a los miemibros del Comité Directive ce fa Organizacion de Aucitoria Informatica La EDPAF decline toda responsabilidad que pudiera sobrevenite Por ‘esta traduccion. Manuel Palco ‘qsume [a plenc responsabilidad de que su version es, 084 eal saber y entender, una traduccién fiel y cierta del original PREAMBULO ...- +++ ++ 1. La naturaleza de ‘Control’... - 2. Estructura de esta publicacion 3. Terminologia empleada en esta publicacion « v NOTA DEL TRADUCTOR ..- sss sseeerreet , vl PARTE I: CONTROLES GENERALES Y DE APLICACIONES CONTROLES DE GESTION «+. s0s0e0r ere oe PLANIFICACION DEL DEPARTAMENTO DE INFORMATICA ....2-. FIT Plonificacion a largo plazo de la organizacion «= HA a eComité de Planficacién o de Diteccién del Departo- mento de Informatica vo... ssceesca secs Hl infor- Pionincacion a largo plazo de! Departamento d méatica ... +++ ol Ponfcacién & Corto piazo de la organtzacién y de! De- portamento de Informética ... «« : Revision de Ia planificacion de portamento de Informatica - POLITICAS, ESTANDARES Y PROCEDIMIENTOS +++ 20000007" 1-4 Politicas . . 1-4 1.22 fstandares ....+ H-4 1.23 Procedimientos . H-4 RESPONSABILIDADES ORGANIZATIVAS Y GESTION DE PERSONAL. 1-5 Lo ubicacién dol Departamento de Informatica en la or ganizacion. ...+- beeen een eens Pr errerree Descripcion de responsablidades dentro det Departa- mento de Informatica. on en Separacion de funciones = Descripcién de puestos del Depa’ Con aay . Pere 1 gelecclOn de Personal... sss see ses asa a H procedimientos de acreditacion de seguridad de! per- sonal. enerererrT TT CIC CELL Procedimientos de baja del personal. Formacién del personal. « oer jarnento de Informét- iii 14 15 16 OBJETIVOS DE CONTROL, 1990. 13.9 Evoluaci6n de la ejecutoria del empleado en el puesto, 11-9 GARANTIA DE CALIDAD DEL DEPARTAMENTO DE INFORMATICA. +-1-10 114.1. Responsobliidad de la garantia de calidad (GE) F110 142. Aspoctos organizativos de Ia funcién de garantio ‘de call- dGd. (GC). cence ecees reece : #1-10 143 “Cualiicacién de! personal de gorantia d |. (EH), coogane rire ae HA aa Ban de tevisién de a garantia de calided. (6): Hl 1448 Revsion por garantia de calidad (GC) del logro de los ‘ob- jetivos del Departamento de informética..« ve F112 1.46 Revision por garantia de calidad (GC), del_cumpl iento eve earandares y procedimientos del Departamento de Informatica. eee eeeceet ete ee oe ae 11-13 1.4.7. Revision por garar sisteMaS ©... sere eee Te Revision por garantia de calidad (GC) de pectos de los funciones del Departamento de Informa- 1.4.9 Informes de las revisiones de garantia de calidad (GC), 1-14 LA FUNCION DE AUDITORIA INTERNA. . -- 1.5.1. Elestatuto de auditoria interna... sss ace 182 Competencia técrica del personal de auditoria interna, 1183 Formacién continuada del personal de ‘auditoria interna. 1184 Rendimiento del trabajo de auditoria intema, 1'3'5_ Informes de la funcién de auditoria interna. « ESPECIFICACIONES DE ORIGEN EXTERNO. «++ 0-00 sce eeso CONTROLES DE DESARROLLO, [ADQUISICION Y MANTENIMIENTO DE SISTEMAS INFORMATICOS."... ss eee seer een e renee perere teers 2-1 21 METODOLOGIA Y RESPONSABILIDAD DEL CICLO DE VIDA DEL DE- SARROLLO DE SISTEMAS. ... ++ 002007 ere 21 2.1.1 Metodologia de ciclo de vida del desarrollo de sistemas. 12-7 2.1.2 Papeles y responsabllidades. «12... - sss 5 vanes b22 2.13. Actualzacion del ciclo de vida del nuevo sistema. 12-2 2.2 INICIACION DEL PROYECTO. 123 2.2.1. Definici6n del proyecto. . erretey 12:3 32.2. Participacién del departamento usuario en la del proyecto... seeeeeeeee seer ees , 12-4 OBJETIVOS DE CONTROL, 1990. 2.2.3 Composicion y responsabilidades del equipo de piciers 12-4 224 125 225 125 2.3. ESTUDIO DE VIABIIDAD . 126 23.1. Formulacién de cursos de accién alternatives. 126 23.2 Estudio de viabilidad tecnoldgica . . . 126 23.3 Estudio de viablidad econémica 127 2.3.5 Aprobacién del proyecto. ...- 128 2.36 Plan diiector del proyecto. 129 2.3.7 Control de costes. 129 2.4 FASE DEDISENO. 2.0... .e0ee sees ere eees 12-10 2.4.1 Metodologio de disefio ......- 2.42. Definicon y documentacién de las os salida. ... 243 Documentacion y definic entrada. ... 244 Defricion y decumentacion de expeciicaciones¢ je fiche: in 245 Especificaciones de prograr Diseno de Ia recogida de datos fuent Disefto de controles y seguridad. Disefio de pistas de auditoria. 2.4.10 Aprobacién del disefio. - 2411 Estondares de documentacion de programas. . 2.4.12. Pian de volidaci6n, verificacin y pruebas. . 2.5 DESARROLLO EIMPLANTACION. «5... 0005+ 2.5.1 Objetivos de programacién. , aed 2.5.2 Descripcién de Ia narrative del programa... . 2.5.3 Paquetes de logical de aplicacién. . .. . ° 25.4 Contratacién de programas de aplicacién a medida. 25.5 Manual de operaciones y eentonmericy 2.5.6 Manual de usuario. 0 2.5.7 Plan de Formacién. ree 38.8 EslGndores de prueba de programas. 259 Estandares de prueba de sistemas. . . .. 25.11 Evaluacion de los resultados de las pruebas 2.5.12 Plan de Conversion. a Tr 2.5.13 Pruebas en Paralelo ; 25.14 Prucba de aceptacién final. 26 27 OBJETIVOS DE CONTROL, 1990. EXPLOTACION Y MANTENIMIENTO. 2.6.1 Procedimientos de contro! de 2.62 Control de cosles. .-.. ++ 2.6.3 Modificaciones al sistema. . ..» , 264 Re-evaluacion de las especificaciones de usuario, .... 12-26 REVISION POST-IMPLANTACION. Pian de revision post-mplantacion. Evaluacién de resuitados. .....- Evaluacion del cumplimiento de las esp usuario. ... +++ met ‘Andlisis de evaluacion coste-beneficio. - Evaluacién del cumplimiento de los e: desarollO. ... ss eeeeeees eee Peete 2.76 Informe sobre los hallazgos de Ia revision postimplant cin. eeener erree erie weve F229 an ONO xR ORRN 3 CONTROLES DE EXPLOTACION DE SISTEMAS DE INFORMACION. .. «+ - 1-3-1 31 3.2 EXPLOTACION. ..- 3.3 PLANIFICACIONY GESTION DE RECURSOS DEL DEPARTAMENTO DE INFORMATICA. . . beeee teen nae 13-1 3.1.1 Presupuesto operativo anual del Departament maética, .....+ ve 3.1.2 Plan de Adquisici6n de Equipos. ... .- 3.13. Gestion de capacidad de los equipos. 32.1 Calendario de carga de trabajo. 3.2.2 Programaci6n del personal. . - 3.2.3 Mantenimiento Preventivo de! Mater 3.2.4 Gestion de Problemas ....- 3.2.5 Gostién de Cambios .....- 3 3.2.6 Contabilidad de Costes de Trabajos . . . 3.2.7 Procedimiento de Facturacién a Usuarios . . - - oe 32.8 Responsablidades de Gestion de ia Biblioteca de Soportes rial Magnéticos ..... ++ mererrer trie , -. 138 3.29 Sistema de Gestion de Ia Biblioteca de Soporte: 1. 19 32.10 Kdentificocion Externa_y Control de Soportes Magnéti cos Serre eee rer a . 13-10 3.2.11 Procedimientos de Explotaci6n 13-10 LOGICAL DE SISTEMA OPERATIVO .... se ee eeeeeoren ices 13-10 3.3.1. Selecci6n de Logical de Sistema .....-- Soper al vi 3.4 36 OBJETIVOS DE CONTROL, 1990. 3.3.2 Andlisis Coste-Beneficio del Logical de Sistema - 333 Instolacion de Cambios en el Logical de Sistema 3.3.4 Mantenimiento del Logical de Sistema... « - « 3.35 Control de Cambios en el Logical de Sistema... 336 Gestion de Problemas con el Logical de Sistema - 33.7 Seguridad del Logical de Sistema . - SEGURIDAD LOGICA Y FISICA 200s seer eens terres 34.1 Responsabllidad de la Seguiidad Logicay Fisica ...... 13-14 3.42 Acceso a las Instalaciones de Ordenadores . . - 1 BB4 3.43 Acompanamiento de Visitos .. . « . 13-15 3.4.4 Administraci6n de Polabras de Paso . 13-15 325 Informes de Violaciones y Actividad de Seguridad .... 13-16 3.46 Restricciones de Acceso L6gico .....-+ Pee 3.47 Seguridad del Acceso a Datos En Linea 3.48 Identificacion Limitada del Centro de Célculo . .. - 3.4.10 Formacion y Concienciacién en Procedimientos de Segurittd8 PLANIFICACION ANTE CONTINGENCIAS «2... 0-2-0 20000+ 13-18 3.5.1 Plan de Recuperacion de Desastres .. . . « seeeeenees EBD 3182. Seguridad del Personal y Formacién en Procedimientos de Emer, GENS se eeee sees eee ees . . 13-19 3.5.3 Aplicaciones criticas de tratamiento de datos - 13-19 35.4 Recursos de Ordenador Criticos .. ++. +++. : 13-20 3.55 Restauracin de Servicios de Telecomunicacion - + 321 3186 Respaldo: Del Centro de Céiculo y de los Equipos ....- 13-21 3157. Piantila de Programacién para Operaciones de Respat [- [oe eer . wees 13-22 3.5.8 Procedimientos de Recuperacién de Ficheros 3.5.9 Consumibles para Recuperacién de Desastres 3.5.10 Pruebas del Plan de Recuperacién de Desastres -.. - 3'5.11 Reconstruccion del Centro de Céiculo del Departamento de informatica .......+ 3.5.12 Procedimientos de Resp: tos Usuarios .... 3 4, CONTROLES DE APLICACIONES 41 CONTROL DE CREACION DE DATOS. «0... - 0 sees rere b4-1 Procedimientos de preparacién de datos. 14-1 Diseno de documentos fuente, b4-1 Control de documentos fuente. 14-2 Sor monte de outorzacion de entiada de datos... 142 Retencion de documentos fuente. ..... + bees +43 BRABE ROR vil OBJETIVOS DE CONTROL, 1990. 42 CONTROL DE ENTRADA DE DATOS. ...-. see eer nesrerer eres M4 42.) Procedimientos de conversion y entrada de datos. . .. a4 42.2 Procedimientos de conversion y entrada de datos en Wned. 0. eee , 145 42.3 Validacién y correc 146 43 CONTROLES DE TRATAMIENTOS DE DATOS... - 2. +20 8000 14-8 Integridad del Tratamiento de Datos .......+..+. . 148 Disposiciones acerca de la integridad del tratamiento de los datos en el logical de aplicacién. os M9 Validacion y Correccién del Tratamiento de Datos. .... 14-10 Manejo de Errores de Proceso de Datos. ..... 411 44 CONTROL DE SAUDAS DE DATOS 2... esse sere creer neers 1411 44.1 Revision de solidas ......-.- 14-12 442 Cuadre y Reconcliiacién de Salidas . 1 h412 443. Disttibucién de salidas. .. .. . : 1 M13 4.4.4 Gestion de errores en las salidas. 4-14 4.45 Manejo y retencion de los salidas . 14-18 4.46 Disposiclones de seguridad sobre Ios informes de salida || 4-16 PARTE Il; CONTROLES ESPECIFICOS DE CIERTAS TECNOLOGIAS 1 CONTROLES EN SISTEMAS INFORMATICOS EN ENTORNOS DE BASES DE DATOS .... eneeenrrrererenrtrrtt trent wl 1.1 SISTEMAS DE GESTION DE BASES DE DATOS . Ie1-1 1.2 ADMINISTRACION DE DATOS ... «os. s aoe H1-2 113 RESPONSABILIDAD DE LA ADMINISTRACION DE LAS BASES DE DATOS 2... cee cee eee ee eee ee eee tes + seeeeeee UTD 1.4 DESCRIPCION DE DATOS Y CAMBIOS DE DATOS .. . 1 115 CONTROL DE ACCESO A DATOS Y DE CONCURRENCIA . .. «. - 116 RECUPERACION DEL CONTENIDO DE LAS BASES DE DATOS .. . 1.7 INTEGRIDAD DE LAS BASES DE DATOS ...... og0oa0 118 _ DISPONIBILIDAD DE LAS BASES DE DATOS . 2. CONTROLES DE EXPLOTACION EN INFORMATICA DISTRIBUIDA Y REDES.... [2-1 2.1 COMPRENSION DE LOS OBJETIVOS DE LA DIRECCION . 2.2 PLAN DE IMPLANTACION ..... free 2.3 ESTANDARES DE CONTROL PARA LA RED... 02.0 2.4 OPCIONES DE CONTROL DEL MATERIAL Y LOGICAL 2.5 DISTRIBUCION DE BASES DE DATOS . te vill OBJETIVOS DE CONTROL, 1990. 2.6 ESTANDARES DE DATOS PARA LA RED -« 2.7 ACCESO A DATOS DE LA RED . 38 MECANISMO DE REVISION DE DATOS DE LA RED 39 DISPOSICIONES SOBRE RESPALDO DE MATERIAL Y LOGICAL 2.10 EXPLOTACION DE LA RED .. «« - 2.11 LOGICAL DE COMUNICACIONES . eee 21D ACCESO AL LOGICAL DE SISTEMA OPERATIVO DE Ui. RED . 2.13 ACCESO A LAS INSTALACIONES DE EXPLOTACION DE LA RED - 2.14 CIFRA (CRIPTOGRAFIA) DE DATOS - «+--+» : 2.15 SEGURIDAD DE LA RED... 2.16 REVISIONES DE SEGURIDAD DE LA RED 2.17 DOCUMENTACION Y FORMACION DEL PEI DELARED coesecssceegee sere 2.18 REVISION POSTMPLANTACION DE LA RED 3119 CONTROL DE FUNCIONAMIENTO DE LA RED 2.20 PLANES DE CONTINGENCIA DE EXPLOTACION DE LA RED 3 CONTROLES SOBRE EL INTERCAMBIO ELECTRONICO DE DATOS ..--+ +++ : 3.1 OBJETIVOS DE GESTION... 3.2 ANALSIS COSTE-BENEFICIO : 33 SELECCION DE SUMINISTRADORES DE SERVICIOS 3.4 TERMINOS CONTRACTUALES | o-oo 3{5 IDENTIFICACION Y VERIFICACION DE USUARIOS 31S CONTROLES DE PROTECCION DE PROGRAMAS -- «+++ = 3S CONTROLES SOBRE EL LOGICAL DE APLICACION -- 3.8 MANUAL DE USUARIO . « 3.9 FACTURAS POR EL SERVICIO . 4 CONTROLES EN LAS OPERACIONES EN LAS OFICINAS DE SERVICIOS ..-- ++ 4.1 EL CONTRATO CON LA OFICINA DE SERVICIOS . 42 MANUALES DE USUARIO : : 4.3 REVISION POR TERCEROS .. - - se eeenes , Ae ASTABLIDAD FINANCIERA DE LA OFICINA DE SERVICIOS ‘45 EL PLAN DE RECUPERACION DE DESASTRES INFORMATICOS DE LOS USUARIOS «0.0 e eee eer eres anenennnrrrEe ey 5 CONTROLES SOBRE ORDENADORES PERSONALES. 5,1 POLTICAS DE DIRECCION, «vee st Bn oo 82 CRITERIOS de ADQUISICION DE ORDENADORES, PERSONALES . -- 23 DESARROLLO Y ADQUISICION DE LOGICAL DE ‘APLICACION . . 34 DOCUMENTACION DE LOS PROGRAMAS oer 0 a 2-4 12-5 2-5 4-1 4-1 Wa-2 15-1 15-1 15-2 15-3 5-4 55 BIBLIOTECA DE PROGRAMAS APLICACION O8TI CENCIA 5.6 FICHEROS DE DATOS . 5.7 FICHEROS DE TRANSACCIONES OF KGCESO A RECURSOS DE ORDENADORES PERSONA\ 5,9 DOCUMENTACION DE LOS PROCESOS 5,10 CARACTERISTICAS DE CONTROL . . 5.11 TRANSMISION DE DATOS CON ORDENADORES RSONALES . 5.12 RESPALDO Y SEGURIDAD DE PROGRAMAS Y DATOS. « 5.13 SEGURIDAD FISICA DE LOS EQUIPOS. -.- | 2.14 OPERAGION DE LOS ORDENADORES PERSONALES 8.16 REVISION POR LA DIRECCION 6 CONTROLES SOBRE REDES DE AREA LOCAL « «+--+ 6.1 POLITICAS SOBRE GESTION DE REDES 6.2 SEGURIDAD LOGICA DE LA RED . - 63 SEGURIDAD FISICA LA RED . 6.4 SOPORTE Y GESTION LA RED Q 65 CONTROL DE CAMBIOS EN LA RED 71 SELECCION DE LA APLICACION 72 DISENO «0... 73 ADQUISICION DEL CONOCIMIENTO 7A PRUEBAS «0.0.55 : 7.5 MANTENIMIENT 7 FORMACION Y SUPERVISION 7.7 ACCESO eo APENDICES INDICE ANALITICO APENDICE A: CONTRIBUYENTES A ESTA PUBLICACION APENDICE B: GLOSARIO INGLES - ESPANOL UTILIZADO OBJETIVOS DE CONTROL, ENIDOS BAJO L- 1990. COBJETIVOS DE CONTROL, 1990. PREAMBULO E1 Papel del Auditor Informatico en el desarrollo y revisi6n de controles para sistemas informatizados. Esta publicaci6n es el resultado del anéiisis, la revision, y Ia ampliaci6n profundos de eee blcacion editada en 1.983 bolo el {fe ‘Control Objetives: Controls In A une Over Environment: Objectives, Guidelines: one “Audit Procedures (Objetivos de cori Controles en un Entome Informatizado: Objetves, Directivas y Procedimientos de Auditoria). Esta ‘edicion de 1.990 desarrolla !a concepcion de Ja version de 1.983 Grrpliondo eu cobartura a una variedad de tecnologios informatica y sus correspon dientes controles. Esta publicacion ‘esta concebide para ‘ofrecer a la alta direccion. de Informatica y a sus Auditores iinforméticos una guia actualizada y completa Ce rente a 1 que pudiera denominarse 10 Duend! practica en Ia creacion. ‘Speracién, verificacion y evaluacion de controles en un entomno informatizado. Bobiera resuitar también til a otras personas Con Uh interés continuado en evaluar la calidad y eficacia general de tales controles Dichos grupos adicionales incluyen - “sin quedar limitados a— reguiadores, Jegisladores, ‘aseguradores de siniestros y respon- sobliiades. investigadores y formadores en ‘este campo. y el gran pUblico. El objetivo de quienes hen contribuido a Ia ‘organizacion y presentacion de este material es crear un estandar con el que puedan medirse los esfuerzos para establecer Y Srontener ol control de sistemas informatizades. 1. La naturaleza de “Control” En un entomo informatizado, se define el control par ave abarque los polticas. procedimientos, précticas. y estructuras organizafvos cr ‘aseguren la edecuacion Bea gestion Ge los activos informatics y la flablided de las actividades de sistemas See Gemnacion, Cuando el control es efectivo, todas las partes interesadas en - 0 Stectadas por — la operacion de los sistemas de informacion en cuestion debieron Stet ana confianza razonable en que se sattstacen los expectativas de fa direccion, Teceicos, profesionales y publica respecto dol proceso da datos en el entomo en (Siaation, Espectficar Ia naturcieza y Gmbito del control en ‘todos los aspectos de sus Sehvidades - incluyendo los sistemas de informacion = 28 cometido de la alte direc Sion de una organizacién. EI Auditor Informatico tiene que contestar dos preguntas fundamentales en el entomo informético: * gs realista la especificacion del control? * yCusn efectivas son las medidas de control? El control es, por su propia naturalezs. relative mas que absoluto. En algunos casos esta limitado por las expectativas de Ia alta ‘direccion de una organizaci6n y Por Gtras partes interesadas. También puede estar limitado por el coste de mantener un 1 OBJETIVOS DE CONTROL, 1990. control en particular cuando se compara con el dano que puede ocasionarse ~ O a pérdida en que puede incurirse - bien por un fallo al Implantar el control, bien por Rao de dicho control en funcionar adecuadamente, Muy rara vez una medida de Control espectfica resultard eficaz por simisma. La eficacia del control, en un entorno Inromético espectfico, 0 para un sistema 0 actividad informéticos en concreto, es, “Entitima Instancla, funci6n de Ia eficacia de todos los controles pertinentes a dicho sistema o actividad. £1 papel de la alta direccién de una organizacion es elercer Julcio rozonable y predenté para definir buenos précticas de control en un envaro de sistemas in- eos oe para evaiucr la eficacia del modo en que tales meditos se non aplicado, y para remediar cudlesquiera deficiencias que se identifiquen. bien 6h Se estructura, eee forma en que han sido aplicades. ¢lincumplimiento de alas practica Slprocadimiente espacfico contenidos en esta publicacién no debiera utilzarse para imputor a la direccion un falo en el uso de Ia prudencia o de fe precauci6n on ol Cumplimiento de sus obligaciones. Antes bien el auditor informético debiera eemocer que un control especifico que puede ser generaimente considerado Seeejabis Implantar on un entomo informético, en ocasiones puede no ser Sconsejable estableceto en un entomo organizativo especifico) El papel del auditor informético, en esta situacion, es actuar como un delegado de laaita direccién para examinar las practicas de control y evaluor su eficacia. Es también funci6n del auditor informar ~en base a lo que ha coroborado mediante su examen-- sobre las conclusiones alcanzades en el proceso de evaluaci6n del Control, y recomendar medidas adecuadas para corregir cudlesquierc deficiencias que pudieran haber sido descubiertas durante este examen y evaluaci6n. Con total independencia de esta actividad de revision de controles. es también apropiado que Slouditor informético aconsele a la alta direccién de la organizacion respecto dela Recesidad de ciertos controles en el desarrollo o revision de los sistemas de informacion existentes y de los procedimientos de tratamiento de la Informaci6n. Es también opropiado que el Auditor Informatico evale cusn bien se han materializado Gichos recomendaciones en el sistema 0 procedimiento acabado y que informe o {ata areccion sobre los conclusiones alcanzades como resultado de esta Svaluacion, En ninguno de esos casos puede suponerse que la independencia de! ‘guditor se haya comprometide en medida alguna por estas actividades. 2. Estructura de esta publicacién La generacién de informacién en une organizacion viene dictada por las necesido, des de sus diversos departamentos y unidades y se lleva a cabo mediante el Sciablecimiento de distintas concepciones o visiones de los datos para sus departa- mentos y unidades. En este documento, ia revision de los controles sobre esto Iormactén se ha dividido en varias secciones, para permitir al auditor revisar lo efciencia y eficacia de tales controles desde diversas perspectives. y no todas elias Sern ules en una revision en concreto. Las secciones estén organizodas en dos partes. La Parte | cubre controles generaies y de aplicacién. Estas areas de control Betn inferrelocionadas y versan sobre aquellas funciones de contro! que son Comunes a cualquier entomo informético. La parte ll complementa a la parte | y OBJETIVOS DE CONTROL, 1990. versa sobre aquellos aspectos del control que son propios de aplicaciones especificas veg tecnologia de 10s sistemas de informacién. Habida cuenta de que 1° de los propésitos de este documento era que cada seccion fuer? ‘autocontenida, con un ood de referencias cruzadas c material presentado en oftas partes de commer fo ontte las diversas secciones tienen lugar clertas peauenas duplicidades y Ciapamientos Se suminista, sin embargo, un indice del contenido de esta Bublicacién para ayudar al lector a determinar cuGndo diversos ferns 50 tratan en a evalferentes secciones. Este indice sefolaré también las éreas de solapamiento. Los contenidos de esta publicacién estén organizados con un formato estructurado. Cade una de los secciones se presenta como una serie de Objetivos de Control y Soclaraciones de Directivas de Auditoria. En os primeros. ¢1 verbo “deberia’ identifica Gna eccion que Ia direccién debiera razonablemente emprender © ‘exigir de otros. En el segundo tipo de declaraciones el verbo ‘debe’ identifica une acci6én que se espera emprenda un Auditor informético. Cada Directiva de Auditoria se comple- erontg con una secuencia de procedimientos de auditoria (denominados también pasos), que el auditor informatico debiera seguir para Identificar la existencia y Bfcacia de los Objetivos de Control significativos. Los verbos que desciben acciones Gel cuditor en estos procecimientos 0 pasos han sido Impresos en Htélficas negritas para agllizar la ullizacién de dichos pasos por el auditor. EI seguir tales pasos eeGmente, sin embargo, no excluye 1a necesidad de que el Auditor Informatico: Gesarrolie programas de trabajo de auditoria exhaustivos para cada exomen © fevision emprendidos. Se reconoce que en muchos entomos de auditoria no es posible exominar cada centro de célculo, cada departamento usuario, o cada Splicacion informatica. Asi pues. en esta pubicacion se sugiere que cuando seo sig- Aificativo, el auditor seleccione una muestra de Ia poblacién mas amplio a examinar, Para que una Directiva de Aucitoria espectfica sea aplicable, deben de estar implan- tados los Objetivos de Control pertinentes. Cuando esa condicién no se da. el Auditor Informatica debiere considerar recomendar a Ia alta direccién de Ia organizacion que se implante dicho control. £1 material contenido en esta publicacion puede citarse en informes u otros Gocumentos de la siguiente forma: Parte/Seccion/Punto. Asi, por ejemplo. la Parte VSeccion 2/Punto 25, se refetitG a todos los obletivos de control, directivas de Gucitoria y procedimientos de auditoria relacionados con el examen por el Auditor nformatico del papel y de Ia responsabilidad de los individuos implicades en el Desarrollo @ Implantacién de una aplicacién informética en una organizacion, fempleando la metodologia de ciclo de vida del desarrollo de sistemas propia de la organizacién, Esta version de Objetivos de Control se publica en formato de hojas cambiables, para faciltar el proceso continuado de revisién y ampliacién de este documento. Tengose presente que Objetivos de Control esta disponible en varios idiomas. OBJETIVOS DE CONTROL, 1990. 3. Terminologia empleada en esta publicaclén En esta publicacién se emplean de una forma particular un clerto nimero de términos. + togical ("software") de programas de aplicacién. Se refiere a aplicaciones informéticas y se emplea indistintamente para programas de aplicacion y para logical de aplicaci6n. * Intercambio electrénico de datos Se refiere « una transmision organizada, ordenador a ordenador, de datos especifica- gos utilzando estructuras de mensojes y formatos acordados entre socios comercia- fos, 0 agencias guberativas a través de una red de comunicacién publica o privada, a efectos de contabilidad, administracion. ‘comercio, transporte y fiscolidad. * sistema experto. Se refiere a una oplicacién informatica que se usa como une guia para la ejecucion Se rutinas de trabajo complejas 0 como una ayuda a Ia toma de decisiones. Un Sistema experto puede ser parte integral de otra aplicacién o puede operar independientemente. Un sistema experto tiene dos componentes: una base de Conocimientos y un motor de inferencic, © concha. La base de conocimientos Contiene regias generales o ejemplos usados por expertos humanos ef Ia toma de Secisiones. La concha es un programa de ordenador que brinda a los usuarios del Soma expert decisions sobre circunstancias especificos, basadas en ta informacion contenida en ia base de conocimientos del sistema experto, * Departamento de Informética. Se roflere a la unidad dentro de una organizacion que suministra ~ 0 coordina el uso So — diversos servicios de tratamiento de Ia informaci6n. El érmino concreto utilizado. para identificar a esta unidad variaré de una organizacion otra. * ordenador Personal (Microordenador) . Identifica un dispositive que, en general, opera de modo independiente y que conse Be tn ieclado u otra unidad de entrada autocontenida, algén tipo de memoria Prema, una unidad central de proceso, una pantallc y una impresora de solide. Un i ySonador personal es normaimente capaz de procesar por si mismo cantiades Significativos de datos. Puede usorse, en algunos Cases, pare comunicor rectorner” te ton ottos ordenadores personales y para compartir datos y fareas con ellos. En Vv OBJETIVOS DE CONTROL, 1990. otras ocasiones un ordenador personal puede emplearse come un terminal para oes oar eon un ordenador central que tenga capacided de tratamiento de datos compatible. * organizacién. Se refiere a cualquier entidad empresarial o publica -tonto s! tiene fines lucrativos Como si se trata de una agencia o Institucion no tucrativa. * Alta direccién. $e refiere a aquellos ejecutivos de la organizacién que pueden formular especifica- SSones genercles de poliicas y procedimientos que definen la forma en que ciertos Sctividades serén desarrolladas por la organizacion y sus componentes. Los titulos Usados para identificar a los indiividuos que pertenecen a esta categoria varian de una organizacién a otra. * sistema o sistema de informacién. Se refiere una colecci6n interrelacionada de programas de proceso de datos, datos, procedimientos de tratamiento de la informacion. asi como a los documentos y registros asoclados con su uso. * Ciclo de vida del desarrollo de sistemas. Se tefiere a un método estucturado a ser seguido para el disefio, creacién, y ‘operacién de un sistema de informacién. Las fases definides para esta metodologia: Varian de una organizacion a otra, pero en esta publicacion se supone que consisten en una iniciacién del proyecto, un estudio de viabilidad, el propio proceso de diseno, al desarrollo € implantacién del disenio del sistema, su operacién y mantenimiento, y una post-implantacion del sistema, ya en la fase concluyente del ciclo. * Departamento usuario. Se refiere a una de las secciones de la organizacién que utiliza informética en su trabajo y al que el Departamento de Informética proporciona alguna forma de servicio de tratamiento de datos. Michael Donahue Beldon Menkus Vice President. Research Editor The EDP Auditors Foundation Tella G. Ruthberg Assistant Editor OBJETIVOS DE CONTROL, 1990. NOTA DEL TRADUCTOR: Lo terminologia informatica en castellano - como otta mucha terminologia técnica - est muy marcada por el inglés y - en muchos Cas0s = los férminos varian mucho de eros o otros entornos. (Piénsese, por ejemplo, en el caso ce Interficie, el termino homologado en el Gmbtto oficial de la Comunidad Europea, pare referirse a interfaz 0 Interfase 9 interface). En toda lo traduccion se ha hecho un esfuerzo considerable para lograr la méxima uniformidad en el vertido de palabras y expresiones, y en Io eleccién de términos generalizados en castellano. El Apéncice Brecoge el Glosario Inglés - Espartol con las Correspondencias de términos que hemos utlizado, vl OBJETIVOS DE CONTROL, 1990. PARTE |: CONTROLES GENERALES V DE APLICACIONES CONTROLES DE GESTION CONTENIDO CONTROLES DE GESTION .-.-- H- 1,1 PLANIFICACION DEL DEPARTAMENTO DE INFORMATICA . - -- b-1 11.1. Pronificacion a largo plazo de ta organizacion, HA 112. Er Comité de Planificacion 0 de Direccion del Departa- mento de Informatica .. «++ eo HW 1.1.3. Pianificaci6n a largo mética .. 1.1.4 Planificacion partamento de Informatica . - veteeeeeeeaes ETS 1:18. Revision de la planificacién de la organizaci6n y del De- portamento de Informatica...» pane vere ES 1.2 POLITICAS, ESTANDARES Y PROCEDIMIENTOS ...-- + +s 0eere es 11-4 12.1 Politicas. . 14 1.2.2 Estandores 14 12.3 Procedimientos . H4 1.3. RESPONSABILIDADES ORGANIZATIVAS Y GESTION DE PERSONAL 5 1.3.1. La ubicacién del Departamento de Informética en 1a or QONIZICION. . sv seeeees see ee nesses ee NS 1.32 “besotipcién de responsabiidades dentro de! Deporto- mento de Informatica. . 15 1.3.3. Separacién de funciones - 4 134 Descripcion de puestos del Departamento de Informati- cone , peenrer er eran g15°) 1.3.5 Seleccién de personal... SernererrTy Tr crt ra aia 136 Procedimientos de acreditacion de seguridad del per sonol. .. +++ Reet e armen al 137 Procedimientos de baja de! personal. . 18 13.8 Formaci6n del personal... ..-. ++ , errr gs 139. Evaluocion de la ejecutoria del empleado en el puesto. ho 1.4 GARANTIA DE CALIDAD DEL DEPARTAMENTO DE INFORMATICA. 1-10 1.4.1. Responsablidad de la garantia de calidad (GC) «> HA10 1/42. Aspectos organizativos de Ia funcion de garantia de cali- dad. (GC). 6. screenees see eeee eee weve FIO PARTE | - 1. CONTROLES DE GESTION. 15 1.6 1.4.3 1.4.4 145 146 1A7 1.49 LA FUNCION DE AUDITORIA INTERNA. 151 162 153 15.4 155 ESPECIFICACIONES DE ORIGEN EXTERNO. Cualiicacion del personal de gorantia de calidad. (GO)! oene eveoneneetes Hy eo sc ievision de la garantia de calidad. (GC)... K-17 Revision por garantio de calidad (GC) del logro de los ob Jetivos del Departamento de Informética. . we HZ Revision por garantia de calidad (GC). del cumplimiento ‘de los estndares y procedimientos del Departamento de Informatica. #1-13 Revsi6n por grant sistemas ove ee eee 1-13 TAD Revsién por garantia de calidad (6C) de otros os- pectos de las funciones del Departamento de Informé- HCO eee cee . Informes do las revisiones de gar’ El estatuto de auditoria intema Competencia técnica del personal d Formacién continuada del personal de auditoria Interna. Rendimiento del trabajo de auditoria interna. Informes de la funcién de auditoria interna. . . 1 CONTROLES DE GESTION 1.1 PLANIFICACION —DEL__DEPAR- ‘AMENTO DE INFORMATICA E1Departamento de Informatica deberia tener planes a corto y largo plazo. a fin de osegurar su contribucion al éxito en €@1 logro de los objetivos generailes de 1a organizacién. Dichos planes debieran ser ‘congruentes con los planes més genero- les de la organizacién para lograr sus propios objetivos. 1.1.1. Planificacién a largo plazo de la organizacién * Objetive de Control. Los planes a largo plazo del Departa- mento de Informatica deberian cubrir aspectos relacionados con su contribu- Gion al logro de los objetivos a largo plozo de la organizacion. La direccién de la organizacion, al més alto nivel, deberia participar en el desarrollo del plan a largo plazo del Departamento de Informatica. La participacion de la alta direccién deberia asegurar que el plan del Departamento esta integrado en el plan general de Ia organizacion. * Directiva de Auditoria. Debe revisarse el plan a largo plazo de la organizacion, Debe prestarse especial consideracion a cuén bien integrada @st6 en el plan general Ia parte relativa ‘al Departamento de Informatica. Deben evaluarse la eficiencia y eficacia de la contribucion del Departamento de Infor- miética. 1. Revisar el proceso de planificacion de Ia organizaci6n para deferminar el nivel de implicacién en el mismo de la alta direcci6n. 2. Revisar partes significativas de las ‘Actas de los reuniones del Consejo de ‘Administracion, del Comité Ejecutivo, de! i OBJETIVOS DE CONTROL, 1990- Comité de Direccion 0 del Comité de Politica de Empresa de la organizacion, ‘dentificar os objetivos a largo plazo de Ia organzacién. 3. Entrevistar a los directivos significa tivos en cuanto a Ia filacién de politicas ‘de lo organizacion, a fin de identificar y comentar las_estrategias a largo plazo relacionadas con los objetivos del De- partamento de informética. 4. Revisar los planes largo piazo do- umentados y los objetivos del Departa- mento de Informética para determinar su compatibllidad con los objetivos ge nerales de la organizacion: 5, Enfrevistar a las principales unidades Usuarias para deferminar a consistencia de las estrategias a largo piazo de la organizaci6n y del usuario, en lo que so refiera a los objetivos del Departamento de Informética. 6. Determinar \a eficiencia y eficacia del plan a largo plazo del Departamento de Informatica. 1.1.2. EI Comité de Planificacion ‘0 de Direccién del Departamento de In- formética * Objetivo de Control. La alta direccién de a organizacion ‘deberia designar un comité de planifica- cién o de direccién que supervise las actividades del Departamento de Infor- mitica. Entre los miembros del comité deberia haber representantes de la alta direccion, del Departamento de Infor- mética y de la direccibn de los departa- mentos usuarios. * Directiva de Auditoria. Debe verificarse la existencia de un ‘comité de planificacion o de direcci6n PARTE | - 1. CONTROLES DE GESTION. del Departamento de Informatica, y debe revisarse su composicion. Debe dejarse establecido que incluye a direc- tivos de departamentos usuarios. 1 Deferminar \a exstencia de un com +6 de planificacién 0 de direccion del Departamento de Informética. y revisar su estatuto. 2. Identificar 1a composicion del comité y verificar que la direccion de los deparr tamentos usuarios est representada en el mismo. 3 Revisar 1a definicin de respon- sobilidades y funciones de! comité, 4. Revisar las actas de las reuniones del ‘comité, asi como sus planes documen- fados, para deferminar la naturaleza y ‘extension de su papel en el proceso de planificacién del Departamento de In- formatica. 5 Determinar silo objetivos del Depar- Ytamento de Informatica y del comité son consistentes con el - y contribuyen all - logro de los planes y objetivos generales de la organizacién. 1.1.3. Planificacién a largo plazo del Departamento de Informética + Qbjetivo de Control. Los planes a largo plazo para el Depar- tamento de Informatica deberian ser congruentes con — y estar integrados en = los planes a largo plazo de Ia alta direccion, Deberian identificar los ob- Jetivos de la organizaci6n, los cambios de Ia misma, los avances tecnolégicos, las disposiciones reglamentarias. * Directiva de Auditoria. Deben revisarse los planes a largo plazo para el Departamento de Informatica _y Compararse con los planes a largo plazo de Ia alta direccion, a fin de determina su congruencia, asi como su compati- bllidad con los cambios organizativos, ‘cavances tecnolégicos y disposiciones regiamentarias previsios. [1-2 1 Revisar los planes a largo plazo del Departamento de Informatica para determinor su congruencia con los obje- fives generales de la organizacion y jones de crecimiento relaciona- das con éstos. 2 Revisar los fuentes de documenta- ‘lon usadas para el desarrollo de los planes a largo plazo y previsiones del Departamento de Informatica. y verificar ‘que la base de esas proyecciones es razonable. 3. Entrevistar a los directivos clave del Departamento de Informética_para lograr una comprensi6n de su conocl- miento tanto de los objetivos del Depar- fomento cuanto de los generales de Ia organizaci6n. 4 Expiorarla comprensién, por parte de los directives clave del Departamento de Informatica, de los avances tecnol6- gicos potencicies, y de los cambios probabies en cisposiciones regamenta- figs aplicables, y las necesidades de conocimientos / pericia del personal, y evaluar su preparaci6n para reaccionar @ tales cambios, en caso de que se produjeran. 5 Determinar si se han distribuido o ‘otras unidades de la organizacion copias de los planes de! Departamento de Infor- matica y evaluar el grado de acepta- cion de los mismos por dichos unidades. 6 Bavieas los organigramas y descrip- clones de puestos vigentes en el De- partamento de Informatica para deter- minar su conformidad general con los planes a largo plazo del Departamento. 7 Identificar avances tecnolégicos es- pecificos y deferminar si han sido in- Corporados a los planes a largo plazo del Departamento de Informatica. & Determinar que se han identificado y localizado en el organigrama de! De- partamento de Informatica los nuevos conocimientos / pericia exigidos por los vances tecnolégicos previstos. 9. Identificar las disposiciones regio ) mentarias de Importancia para Ia ogo” hizacion en general y asegurar que los planes del Departamento de Informatica fon congruentes con esas disposiciones. 10. Evaluar el nivel de eficiencia y oft, Gacia con que se han integrado en é! ian a largo plazo del Departamento de Informatica los avances tecnolégicos.los cambios en las disposiciones regiomen- farlas y las necesidades de conocimien- tos / pericio. 1.1.4. Planificacion a corto plazo de la organizacién y del Departamento de Informatica * Objetivo de Control. Los planes « corto plazo de [a alta direc: gurar que los recursos adecuados del Departamento de Informatica se osig- nan de forma congruente con los planes ‘a corto plazo generales de la organiza- clon. * Directiva de Auditoria. Deben revisarse los planes a corto plazo preparades por Ia alta direccion de ta organizacién. Debe evaluarse la ade- Guacién de los recursos asignados al Departamento de Informatica. asi como ja congruencia y compatibllidad de los planes a corto plazo del Departamento on los correspondientes planes a largo plazo. 1. Revisar los planes a corto plazo de Ig alta direccién e identificar los recursos que se asignan a corto plazo al Departa- mento de Informética. 2. Evaluar ja adecuaci6n de los recur 308 asignados ol Departamento de Infor- matica o corto piazo. 3, Asegurar la congruencia entre los planes a corto plazo y Jos planes ¢ largo plazo del Departamento de Informatica. 3 OBJETIVOS DE CONTROL, 1990. 1.1.5 Revision de la planificacion de ta organizacion y del Departamento de Informética * Objetivo de Control. Deberion suministrarse Informes a la alte Greccion que les permitieran revisor el rogreso de Ia organizacion hacia los objetivos identificados. * Directiva de Auditoria. Deben revisarse los informes de gestion pora obtener pruebos de que 1a alta Gireccion y el comité de planificacion © Ge direccién del Departamento de infor mattica revisan y coordinan las activida- des del Departamento. 1. Determinar \a fecha y naturalezo de Io Gitima revision por la direcci6n de los planes a largo y corto plazo. 2. Inspeccionar los informes de progre- $0 de la direcci6n, en busca de pruebas de logro de objetives. 3, Revisar la frecuencia y precision de los informes sobre proyectos relaciono- dos con los planes a largo y corto plazo. 4, Comparar los gastos reales con los presupuestados para ideniificar diferen- las significativos. 5. Enfrevistar_ a usuarios y direccion para deferminar si se han alcanzado ‘como se deseaba los objetivos especifi- cos. Revisar, si procede, los informes de gestion espectficos y las respuestas a 10s mismos relativas a aquéllas Greas en que no se han alcanzado los objetivos. 6. Determinar, en ausencia de informes formoles, si hay una comunicacién infor: mal adecuada de las actividades del Departamento de Informética a la alte direccién. PARTE | - 1. CONTROLES DE GESTION. 1.2 POLITICAS, ESTANDARES Y PRO- CEDIMIENTOS Deberia haber politicas, estindares y procedimientos, que sirvieran de base ora Ia planificacion, control y evaluo- clon por la direccién de las actividades del Departamento de Informética. 1.2.1. Politicas * Objetivo de Control. La alta direccién deberia desarroliar, y comunicar a todos los afectados, direct Vos de politica que definiesen Ia relacion ‘entre el Departamento de Informatica y Jos departamentos usuarios. * Directiva de Auditoria. Determinor lo existencia y adecuacién de declaracio- nes de politica por parte de !a atta dk reccién. y confirmar que han sido comu- nicadas a los departamentos pertinen- tes. 1. Revisar las declaraciones de politica de a alta direccién, y determinar que estan actualizadas. 2. Determinar que las declaraciones de politica de Ia alta direccion se han co- municado a las direcciones tanto del Departamento de Informatica cuanto de los departamentos usuarios. 3. Revisar y evatuar ia Integracién de las directivos de politica de Ia atta direc- cién enelestatuto del Departamento de Informética y de los principales departa- mentos usuarios. 1.2.2 Estandares * Objetive de Control. Deben definirse, coordinarse, mantener se, y comunicarse a todo el personal ‘afectado, esténdares que regulen la adquisicion de recursos, 61 diserto, desa- trollo y modificacién y explotacién de H-4 sistemos del Departamento de Informati- ca. * Directiva de Auditoria. Deben revisarse los estandares que regu- en la adauisicion de recursos, el diseno, desarrollo y modificaci6n y explotacién de sistemas del Departamento de Infor- mética. 1. Evaluar el proceso de desarrollo, aprobacién, distrioucion y actualzacion de los estindares aplicables al Departa- mento de Informética. 2. Revisar los estandares aprobados, para evaluar la extension de su docu- mentacion formal, su calidad, vigencia y cuan completos son. 3. Revisar los manuales de operaciones y procedimientos aplicables para defer minar que los procedimiento relativos a la adauisicion de recursos del Departo- mento de Informética cumplen los es- téndares que reguian dichas adquisi- ciones. 4. Revisar los manuales de operaciones y procedimientos tanto en el Departa- mento de Informatica cuanto en los de- partamentos usuarios para deferminar sucumplimiento de los est6ndares relati- vos al disefio, desarrollo y modificacién de sistemas de informaci6n. 5. Revisar los manuals de operaciones y procedimientos del Departamento de Informatica para determinar que los declaraciones de procedimiento relati- vas a Ia operacién de dicho Departa- mento cumplen los esténdares que regulan dicha operaci6n. 1.2.3 Procedimientos * Objetivo de Control. Deben establecerse, coordinarse, man- fenerse y comunicarse a todos los de- partamentos afectados, procedimientos que describan la forma y las responsablli- dades de ejecutoria para regular las relaciones entre el Departamento de Informética y los departamentos usr , tlos. * Directiva de Auditoria. Deben revisarse los procedimientos one ativos relatives a las responsablidades de ejecutoria en las relaciones entre departamentos usuarios y el Departo- mento de Informética. 1. Evaluar el proceso por el que se de- sorrolian, aprueban, distribuyen y OC” fualizan las declaraciones de proced mientos 2. Revisar los manuales de operaciones y procedimientos del Departamento de Informatica para lar 1a extension dela documentacién formal, del Depar- fomento, su Calidad, grado de vigencia y cuén completa es. Evaluar |a ade- Guaci6n de las instrucciones escritos que ‘se refieren alas actividades del Departa- mento de Informatica. 3, Revisar los manuales de operaciones Y procedimientos de los departamentos Usuarios para apreciar Ia extension de su documentacién formal su calidad. grado de vigencia y cuén completa es: Evaluar ia. adecuacion de las instruccio- nes escritas que cubren las relaciones de este departamento con el Departamen- to de Informética. 4. Entrevistar ol personal tanto del De- portamento de Informatica cuanto de jos dopartamentas usuarios para apre- ciarsu comprension de los procedimien- tos aprobados. 1.3 RESPONSABILIDADES ORGANIZA- TIVAS Y GESTION DE PERSONAL EIDepartamento de Informatica deberia serio bastante importante en Ia jerarquia de la organizacion para permitire lograr sus objetivos generales establecidos y promover su Independencia operative Ge los departamentos usuarios. Para promover Ia ufiizaci6n efectiva de los 15 OBJETIVOS DE CONTROL, 1990. recursos humanos del Departamento. y para faclitar la evaluacion del desem- perio dentro de Ia funcion Informatica, Peberian emplearse tecnicas de gestion de personal sdlidas. 1.3.1 La ubleacién del Departa- mento de Informética ‘eniaorganizacion. * Objetivo de Control. Lo alta direccion deberia colocar el De- portamento de informatica lo bostante ‘alto en Ia estructura organizative como para asegutar su Independencia de los departamentos usuarios. * Directiva de Auditoria. ‘Apreciar lo adecuado de Ia ublcacion ‘dol Departamento de Informatica en ta estructura de la organizacion y evaluat el grado de independencia de! Departa- mento respecto de los departamentos usuarios 1. Revisar 1a ubicacién del Departa- mento de Informatica en Ia jerarquia de la organizaci6n y apreciar su indepen- dencia de los departamentos usuarios. 2. Entrevistar al Director del Departo- mento de Informatica para deferminar su apreciacion de la independencia del Departamento respecto de los departa- mentos usuarios. 1.3.2. Descripeién de responsabi- lidades dentro del Departamento de In- formética. + Qbjetivo de Control. Deberian estar descritas las principales Unidades organizativas que constituyen el Departamento de Informatica, ost ‘como perfiades y documentadas sus responsabilidades. + Directiva de Auditoria. Revisar las descripciones de las princ- pales unidades organizativas que const fuyen el Departamento de Informatico y PARTE | - 1. CONTROLES DE GESTION. apreciar la adecuacién de dicha docu: mentaci6n. 1. Identificar_1as principales unidades corganizativas que constituyen el Depar- yamento de Informatica examinando los corganigramas pertinentes. 2. Revisar los manuales de proced- mientos pertinentes para determinar que las responsabilidades asignadas a cada una de las principales unidades ‘organizativas estan enunciadas adecua- damente, y que los procedimientos de evaluacién de su ejecutoria estén ade- cuadamente presentados. 3. Entrevistar al personal supervisor de cada una de las principales unidades ‘organizatives del Departamento para deferminar. @. que su comprension de las res- ponsabllidades asignadas a la unidad, el desempefio esperado y los proced- mientos de evaluacién se corespon- den con los descritos en los manuales b. que su responsabilidad para la Introduccién y uso de nueva tecnolo- gia ha sido definida claramente den- tro del Departamento de Informatica (por ejemplo, la distincién entre el grupo de apoyo a usuarios finales y grupo de desarrollo de sistemas) y entre el Departamento y los departa- mentos usuarios. 1.3.3. Separacién de funciones * Objetivo de Control. La alta direccién debe establecer una separacion de funciones dentro del De- portamento de Informatica, por ejemplo entre desarrollo de sistemas _y explota- cién, entre explotacién y control de datos, y entre administracién de bases de datos y desarrollo de sistemas. * Directiva de Auditoria. Hay que apreciar la adecuacién de la separacion de funciones dentro del De- partamento de Informatica, 6 1. Examinar los organigramas y des- cripciones de puestos pertinentes para deferminar que en el Departamento de Informética existe ia adecuada separo- clon de funciones, Incluyendo la separa- ion entre los siguientes pares de unido- des organizativas principales: ©. desarrollo de sistemas y explota- ci6én b. explotaci6n y control de datos c, administracion de bases de datos y desarrollo de sistemas. 2. Revisar las descripciones de tareas u ‘otra documentaci6n referente a las ta- reas para determinar que se mantiene la separacién de funciones deseada. 3. Observar las actividades del perso- nal del Departamento de Informatica para confirmar ja naturaleza y extension del cumplimiento de esta separacién de funciones deseada. 4, Revisar las asignaciones significativas de suplencias 0 apoyos para asegurar que se mantiene la adecuada separa- cién de funciones. 1.3.4 Descripcién de puestos del Departamento de Informatica * Objetivo de Control. Las descripciones de puestos del De- partamento de Informética deben man- fenerse por escrito y perfilar claramente tanto la autoridad cuanto la responsabi- lidad, Las descripciones deberian incluir definiciones de los conocimientos / peri- Cia tecnicos requeridos pare las posicio nes relevantes y deberian ser adecuadas para ser empleadas en evaluaciones de ejecutoria, * Directiva de Auditoria. Deben revisarse las descripciones de puestos de! Departamento de Informé- tica en cuanto a su adecuacién y clart- dad, a la Inclusion de las descripciones de los conocimiontos /pericia téenicos y fen cuanto a su utilidad como una base para evaluar las ejecutorias. 1. Obtener y revisar los descripciones de puestos empleadas dentro de! De- partamento de Informatica para apre- ciar su adecuacién y clarided. 2. Comparar dichas descripciones con Jas responsabllidades en vigor de quie- nes ocupan tales posiciones, para deter- minar \a precisién de las declaraciones. 3. Deferminar, mediante entrevistas y ‘aNGlisis, que Ia finea directa de autori- dad asociada con Ia posicién es con mensurable con las responsabilidades del interesado. 4, Apreciar los cambios significativos en a organizacion y en la descripcion de puestos en cuanto a su adecuacién y precision en el contexto de los objeti- vos y politicas actuales del Departamen- to de Informatica. 5. Enfrevistar al personal del Departa- mento de Informatica para deferminar ‘que las descripciones de sus puestos les han sido adecuadamente comunicadas, y que el interesado las entiende. 6, Revisar las fechas de validez de los descripciones de puestos, para asegurar que estén en vigor. 7. Determinar que los descripciones de puestos incluyen descripciones de cono- cimientos / pericia técnicos. Evaluar cudn adecuadas son esas descripciones. 8. Determinar que, en las descripciones de puestos, los textos que describen los conocimientos / pericia tecnicos del interesado estan en vigor. 1.3.5 Seleccién de personal * Objetivo de Control. Las précticas de contratacién y promo- ién del personal deberian basarse en bs? OBJETIVOS DE CONTROL, 1990. ciiterios objetivos y deberian contemplar a formacién, la experiencia y la respon- sobliidad, * Directiva de Auditoria. Debe apraciarse la adecuacién del pro- ceso de seleccién de personal en lo que tespecta al Departamento de Informéti- ca. 1. Identificar’ y evaluar los métodos empleados para cubrir vacantes, tales como el uso de promociones internas, firrnas externas de seleccion de personal. u otros métodos apropiados. 2. Evaluar ja adecuacién de los crite- rios empleades para reclutar y seleccio- nar miembros de la plantilla del Departa- mento de Informética, y para ello: a. entrevistar a la direccién del De- partamento en lo que respecta a estos criterios b, _revisar los documentos apropic- dos, como descripciones de puestos, ‘en cuanto a si son claros y completos. 3. Revisar 1a adecuacién de las polfti- cos de seleccién empleadas por ol Departamento de Relaciones Laborales y por el Departamento de Informatica. 1.3.6 Procedimientos de acredi- faci6én de seguridad del personal. * Objetivo de Control. El personal del Departamento de Infor- mética, antes de ser contratado. debe- tia ser objeto de una acreditacién de seguridad, * Directiva de Auditoria. Deben revisarse los procedimientos rela- tivos a Ia acraditacién de seguridad del PARTE I - 1. CONTROLES DE GESTION. personal del Departamento de Informé- fico. 1. Revisar los documentos relativos a la politica de contratacién de personal de la arganizaci6n para determinar que se han establecidos procedimientos de acreditaci6n de seguridad. 2. Entrevistar a los responsables de ‘contratar al personal del Departamento de Informética para determinar que hay implantados procedimientos adicionales de acreditacién de seguridad. 3. Revisar las fichas del personal del Departamento de Informatica para determinar que: ‘a. sahhan seguido los procedimientos de investigacion de seguridad asocia- dos con Ia contratacion del nuevo personal, de conformidad con los estandares de la organizacion b. se han seguido procedimientos perlédicos de Investigacién de seguri- dad del personal. 4, Determinar que los procedimientos de Investigacion de seguridad seguidos son congruentes con las leyes aplicables relativas a la proteccién de Ia intimidad. 1.3.7. Procedimientos de baja del personal. * Objetivo de Control. Deberian establecerse procedimientos pertinentes para la baja del personal del Departamento de Informética y para asegurar la proteccién de los recursos constituidos por los ordenadores y los ficheros de Ia organizaci6n. * Directiva de Auditoria. Debe revisarse la adecuacion de los pro- cedimientos de baja del personal del Departamento de Informética para aseguror la proteccién de los recursos 11-8 constituidos por los ordenadores y los ficheros de la organizacién. 1. Revisar los procedimientos escritos télativos al personal para_deferminar que los procedimientos de baja de em- pleades oplicables al personal del De- portamento de Informatica son, genera mente, conformes con: a. al personal del Departamento de Informatica que causa baja, se le paga, en lugar de permitire que tra- Boje durante el period hasta que Ia baja sea plenamente efectiva b. alos empleados que causan baja se les requiere para que retornen todos los documentos y tarjetas de identificacién suministrados por lo organizacién; en concreto aquéllos que pudieran ser empleados para lograr un acceso no autorizado, des- pués de Ia baja, a instalaciones o datos que tienen asignado algun nivel de seguridad c. al personal del Departamento de Informatica al que se comunica fa baja, se le acompana hasta el exterior de los locales de la organizacion de forma inmediata y sin darie la opor- tunidad de dafiar las instalaciones informaticas © los ficheros de Ia orga- nizoci6n d. después de Ia boja del empleado concreto, se cambian inmediatamen- te las palabras de paso u otros dispo- sitivos de control empleados para lograr acceso a los recursos informati- cos. 2. Determinar que estos procedimientos son seguidos de forma congruente. pro- cediendo a: a. entrevistar a |a direccién del De- partamento de Informatica b. revisar_ las fichas de personal referentes a empleados que hayan causado boja recientemente c. revisar los registros de los sistemas de seguridad de accesos fisicos y de control de accesos al ordenador para comprobar que los accesos de los empleados que han causado baja se han desactivado adecuadamente. 1.3.8 Formacién del personal. * Objetivo de Control. Deberia darse orientacién a los emplea- dos, desde su contratacion. y también formacién continuada para mantener sus conocimientos / pericia. * Directiva de Auditoria. Deben evaluarse los procedimientos de ‘oflentaci6n y formaci6én al personal de plantila del Departamento de Informati- ca, 1. Revisar_el manual del empleado para deferminar que a los nuevos em- pleados se les brindan programas de otientacion que cubren los requisitos de seguridad y control. 2, Asegurar que a los nuevos emplea- dos, durante las sesiones de orlentacion. se les hace tomar plena conciencia de los objetivos de la organizacién y del Departamento. 3. Determinar que los programas de formaci6n de la organizacién son con- gruentes con los requisitos minimos suge- ridos porlas organizaciones profesionales para el Departamento de Informatica 4. Entrevistar a miembros de lo plantila del Departamento de Informatica para determinar que estén informados tanto de los programas de informética patroci- nados por la organizacion como de los requisitos de formacién continua de las organizaciones profesionales, en éreas relacionadas con las del Departamento, de las cuales son miembros 0 a través de las cuales reciben certficaciones u homologaciones profesionales. Ho OBJETIVOS DE CONTROL, 1990. 5. Revisar los calendarios de forma cidn, las descripciones de los Cursos, los métodos y técnicas de formacion, para determinar que tales programas son adecuados para mantener las necesida- des actuales y a largo plazo, tanto de la ‘organizacién cuanto de los empleados. 6. Delerminar que en el programa de formacién se incluyen cursos especifi- camente orientados a aumentarlacom- prension de los objetivos de control del Departamento de Informatica respecto ala gestion, las aplicaciones, y la explo- tacién (u operacién). 7. Entrevista a miembros de la plantila del Departamento de Informatica para determinar \a eficacia de la formacion que se les ha brindado. 8. Comparar las fichas de formacion de los miembros de Ia plantiia de! De- parfamento de Informética con sus exigencias de conocimientos / pericia, para evaluar cuén adecuada y actual- zada es |a formacién que estan recibien- do. 1.3.9 Evaluacién dela ejecutoria del empleado en el puesto. * Objetivo de Control. Deberia evaluarse, de forma periédica, laejecutoria del empleado en compara- clon con estandares establecidos y con responsabilidades espectficas del puesto. * Directiva de Auditoria. Deben de evaluarse los métodos de evaluacién del desemperio de los miem- bros de Ia plantilia de! Departamento de. Informética. 1. Revisar los procedimientos estableci- dos para determinar que se efectuan evaluaciones periddicas del desempono del empleado de conformidad con dichos procedimientos. 2. Entrevistar a. la direccion del Depar- tamento de informética para determinar tanto su comprensi6n cuanto su uso de los métodos de evaluacién del desem- PARTE | - 1. CONTROLES DE GESTION. peno de los empleados establecidos por a organizacién. 3, Entrevistar a miembros escogidos de io plantila del Departamento de Inform- Gtica, para determinar. 0. sucomprensién de los estandares de rendimiento establecidos b. su comprension de las responsabt lidades singulares de su puesto cc. que los resultados de las evaluo- clones han sido comunicados a los ‘empieados de forma congruente con los procedimientos establecidos. 14 GARANTIA DE CALIDAD DEL DEPARTAMENTO DE INFOR- MATICA. Deberia asegurarse la calidad de los servicios prestados por el Departamento de Informética mediante el establec!- miento de una funci6n independiente dentro del Departamento dedicada a mantener esténdares de calidad esto- biecidos, 1.4.1 Responsabilidad de la garantia de calidad (G.C.) + Objetivo de Control. La responsabilidad de llevar a cabo lo funcion de GC deberia asignorse a miembros de {a plantila del Deporto- mento de Informética. Cuando sea adecuado, debera establecerse un grupo independiente de GC. dentro del Departamento. La unica responsabilidad de dicho grupo deberia ser el realizar funciones de GC. + Directiva de Auditoria. Debe realizarse un andlisis para deter minar la necesidad de establecer un grupo formal de GC. 1. Evaluar el nivel general de satisfac- cién de los usuarios con el servicio brin- dado por cl Departamento de Informati- ca. 11-10 2. _ Revisar los registros existentes de problemas, peticiones de programas. Sistemas y do servicios. pendientes de cumplimentar, Deferminar la presteza ‘con que el Departamento de Informéti- ca responde a tales peticiones. 3. Determinar s\ las necesidades de los ‘departamentos usuarios se han sotisfe- cho de forma general, mediante a introduccion de nuevos equipos, comu- nicaclones, programas de sistemas y programas de aplicacién en los ultimos anos. 4, Determinar si se cumplen de forma Ccongruente los estandares y procedi- mientos del Departamento de Informéti- ca, 5, Apreciar, basandose en Ia extension de los hallazgos negativos de los pasos 1.23 y 4 anteriores, si deberia estable- cerse un grupo Independiente de GC en @1 Departamento de Informatica. 1.42 Aspectos organizativos de Ja funcién de garantia de calidad. (6C). * Objetivo de Control. Cuando exista un grupo independiente de GC en el Departamento de Informa- fico, dicho grupo deberia tener un esto- futo escrito aprobado por un nivel de di- reccién adecuado. La funcién de este grupo deberia ser apoyada por la direc- clon tanto del Departamento de Infor- matica cuanto de los departamentos u- suarios. Si lo adecuado es que sean 3610 una © dos personas las que hayan de desarollar la funcin de GC, deberia existir una documentacién clara de sus responsobilidades, aprobada por la direccién. Aun asi, es necesario el apoyo tonto de la direccién de! Departamento de Informatica cuanto de la de los de- partamentos usuarios. * Directiva de Auditoria. Deben revisarse los aspectos organizatl- vos de la funcion de GC del Deporto- mento de Informatica. 1. Determinar que se ha publicade un estatuto debidamente aprobado- del grupo de ‘GC 0 un documento descri- Biendo las responsabiidades de la activ- dad de GC de una dos personas y que describe los deberes. responsoblli- dades, autoridad e imputabilidad del grupo o de la persona © personas. 2. Determinar que el estatuto o docu- mento esté complementado por des- cripciones de tareas actualizadas que incluyen una descripcion de responsabr- idades. 3. Verificar que a la funcién de garan- fia de calidad no se le ha asignado nin- guna de las responsablidades operativas del Departamento de Informatica. 4. Verificar que Ia funcion de GC infor- ma a un nivel de direccion adecuado que aseguraré que las recomendacio- nes se lleven a cabo. 5. Determinar que |a funcién de GC tecibe adecuado apoyo econdmico para completar eficazmente sus respon- sabllidades. 6. Revisar documentacién seleccio- nada recabada al personal de GC para ‘apreciar la amplitud y profundidad de su cobertura de las actividades del De- portamento de Informatica. 7. Entrevistar a 'a direcci6n tanto de los usuarios cuanto del Departamento: de Informatica para determinar que brindan apoyo a la mision y al trabajo del personal de GC y obfener pruebas pare documentar sus ‘afirmaciones. 1.4.3 Cualificacién del personal de garantia de calidad. (GC). + Objetivo de Control. En la funcién GC del Departamento de Informatica deberia haber pericia ade- cuade en los temas de sistemas, con- troles y comunicaciones. hl OBJETIVOS DE CONTROL, 1990. + Directiva de Auditoria. Deben revisarse las cualificaciones de! personal de GC del Departamento de Informatica. 1. Determinar que el personal adscrito Gla funcién GC del Departamento de Informética tlene un conocimiento ade- ‘cuado de la expiotacién del sistema y de lenguajes de programacion. 2. Verificar que el personal asignado a ja funcién GC del Departamento de informética tiene un amplio conocimien- to de las operaciones empresariales, de los conceptos de control intemo y de los controles de proceso de las aplicacio- nes. 3. Determinar que usuarios clave for- man parte del equipo de GC o que son consuttados periédicamente durante el proceso de GC. 4. Determinar que el personal asignado Gla funcién GC del Departamento de Informatica recibe entrenamiento y formacion adecuados, de forma conti: nua. 5, Asegurar que el supervisor de la funcién GC del Departamento de Infor mética tiene pericia adecuadas de supervision, comunicacion y gestion de proyectos. 6. Determinar que \a funcién GC det Departamento de Informatica ha sido adecuadamente dotada de plantilla, en base alos resultados de los pasos 1.2.34, y 5 anteriores, sefalando cualquier defi- Ciencia y su impacto en la eficacia de la funcion GC. 1.4.4 Plan de revision de la ga- rantia de calidad. (GC). * Objetivo de Control. Deberian desarroliarse, mantenerse y estandarizarse planes generales de go- rantia de calidad, calendarios y proceci- mientos, dentro del Departamento de In- formatica, para fiar criterios para el trabajo del personal de GC del departa- PARTE 1 - 1. CONTROLES DE GESTION. mento. Tales planes, calendarios y pro- ‘cedimientos deberian usorse para esto- blecer la congruencia de los resullados alcanzados por dicho personal y para brindar una base para la gestion de las funciones de GC del departamento. * Directiva de Auditoria. Debe apreciarse lo apropiado de los planes de revision de GC en el Depar- famento de Informatica. 1. Evaluar los planes de revision de GC existentes en el Departamento de Infor- miatica, ast como los calendarios y pro- cedimientos. Apreciarsu aplicabilidad y ‘oportunidad comparandolos con las tevisiones realmente llevadas a cabo. 2. Determinar que los revisiones de GC del Departamento de Informatica han sido programadas de conformidad con las prioridades establecidas por la direc- cién del Departamento. 3. Determinar que el personal de GC del Departamento de Informatica usa programas especiales de auditoria para las funciones de investigacién que pue- den ser facilmente automatizades. 4. Verificar_que, tras cada revisibn principal de GC, los planes de revision pertinentes y los procedimientos se eva- idan y mejoran, en la medida que pro- ceda, para contribuir a la mejora de lo eficacia de Tuturas revisiones. 5, Verificar que inmediatamente des- pués de [a terminacion de cada revision de GC, los requisitos de nivel de pericia y experiencia para llevar a cabo to siguiente revision se incorporan a los planes de GC de! Departamento de Informatica. ha 1.45 Revisién por garanfia de calidad (GC) del logro de los objetivos del Departamento de Informética. * Objetivo de Control. Las responsabliidades de GC deberian Incluir una revision de cémo sistemas y ‘oplicaciones concretos han jugado un papel en el logro de los objetivos del Departamento. * Directiva de Auditoria. Debe evaluarse Ia documentacién rela- clonada con las revisiones por el perso- nal de GC de cémo sistemas y aplico- Clones concretos han jugado un papel en el logro de los objetivos del Departa- mento. 1. Revisar os resultados de la revision por el personal de GC de los pl: caciones. Entrevistdr al personal de GC que llevé a cabo [a revision y deferminar que las especificaciones originales del usuario sirvieron como base fundamental para la evaluacién de Ia aplicacion que se revis6, 2. Verificar que esta revision incluy6 la ejecucién de pruebas de calidad tanto del disefio de sistemas pertinentes cucn- to de las actividades de programacién y que las especificaciones de disefios pertinentes se cumplieron. 1.4.6. Revision por garantia de c- | alidad (GC), del_cumplimiento de los esténdares y procedimientos del Depar- tamento de Informética. * Objetivo de Control. Los responsabllidades osignadas al per- sonal de GC deberian incluir una revision ‘del cumplimiento general de los estén- daresy procedimientos del Departarnen- fo. + Directiva de Auditoria. Debe revisarse a documentaci6n relo- cionada con la revision por el personal de GC, del cumplimiento general de los estandares y procedimientos del Depar- tamento. 1, Determinar que el personal de GC ha desarrollado una metodologia para rev- sar y documentar el cumpiimiento de los estandares y procedimientos de! Depar- famento. 2. Asegurar que el personal de GC emplea consistentemente esta metodo- ogia u otros procedimientos estndor. 3. Verificar que los informes del personal de GC describen de forma especifica el cumplimiento de los estandares y proce- dimientos del Departamento. 1.47. Revisién por garantia de calidad (GC) de los controles de siste- mas * Objetivo de Control. Las responsabilidades asignadas al per- sonal afecto a GC deberian incluir una revision de los controles generales del sistema. + Directiva de Auditoria. Debe revisarse la documentacion rela: Gionada con los anélsis de los controles generales del sisterna por el personal de cc. 1. Identificar los controles de sistemas que fueron seleccionados para las revi- H-13 OBJETIVOS DE CONTROL, 1990. siones de GC y apreciar que tales rev siones eran razonables y completas. 2. Verificar que os informes suminis- trados por el personal de GC Incluyen espectticamente los resultados de los hallazgos en las revisiones de control. 1.48 Revisi6n por garantia de calidad (GC) de otros aspectos de los funciones del Departamento de Informé- tica * Objetivo de Control. Las responsabilidades asignadas al per sonal de GC deberian incluir una revision de otros aspectos de las funciones del Departamento que merezcan Ia aten- clén de la direccién. * Directiva de Auditoria. Deben revisarse las directivas relativas 0 las responsabiidades del personal de GC ‘en la revision de otros aspectos de las funciones del Departamento de Info- rmatica. 1. Determinar que las responsabllidades csignadas al personal de GC incluyen una revision de lo siguiente: a. especificaciones reglamentorias y legoles b. la calidad de disefio del sistema c. la calidad de la programacion y las operaciones d. Ia adecuacién de las pruebos de sisternas y programas @. los conocimientos y pericia del personal del Departamento f. la extansi6n y naturaleza de Ia por ticipacién, de los usuarios en las act vidades de desarrollo y mantenimiento de sistemas de! departamento la calidad de la documentaci6n de sistemas y programas PARTE | - 1. CONTROLES DE GESTION. h. Ia. calidad de los datos y de la in- formaci6n. 2. Seleccionar informes producidos por el personal de GC relativos a las reas ‘enumeradas en el paso 1 de Ia seccién 1.4.8 anterior y apreciar la calidad de! trabajo levado a cabo en las revisiones. 1.49. informes de las revisiones de garantia de calidad (GC). * Objetivo de Control. Deberian elaborarse y presentarse a la direccién de los usuarios y de! Departa- mento de Informética, informes de las revisiones de garantia de calidad. * Directiva de Auditoria. Debe evaluarse la calidad y utlidad de {os informes preparados por el personal de GC del Departamento de Informét- ca 1. Seleccionar informes relatives a distintos tipos de revisiones de GC y ‘asegurar que los mismos: @. _comunican eficazmente los ha- Nlazgos significativos de la revision b. estén escritos claramente y con una estructura orientada a la gestion ¢. _ incluyen un resumen para la di- recci6n con una breve introduc- cin, los objetivos generales. el informe general, los _hollazgos significativos y su impacto en el negocio d. _ incluyen una seccién de apoyo, detallada, que contiene reco- mendaciones. 2. Entrevistar al personal de GC que ev6 a cabo las revisiones y deferml- nar su apreciacion de los resultados, Comparar su apreciacién con los Contenidos de los informes pertinentes, 3. Verificar que la direccion de los departamentos usuarios y del Depar- ha tamento de Informatica recibleron en un plazo adecuado copias de los informes de GC. Deferminar su apre- clacién del valor de los informes. 1.5. LAFUNCION DE AUDITORIA INTER- NA. Deberia establecerse, de forma com- ntaria a otros elementos de los controles de gestion, una funcién de quditoria interna, con suficiente compe- tencia técnica, Independencia, y autor dad para efectuar revisiones objetivas de los controles de los sistemas de infor- macién y para preparar y presentar informes de sus hallazgos y recomen- daciones de mejora en todas las Greas funcionales del entorno de sistemas de informatica de Ia orgonizacion. 1.5.1 El estatuto de auditoria interna * Objetivo de Control. La alta direccién de la organizacién deberia establecer un estatuto de la funcién de auditoria interna. Este docu- mento deberia esbozar Ia responsablii- dad, autoridad e imputabilidad de Io funcién de auditoria interna, Deberia revisarse periédicamente el estatuto para asegurar que se mantienen la inde- pendencia, autoridad € Imputabllidad de la funcién de auditoria interna. * Directiva de Auditoria. Debe efectuarse una revision periodico del estatuto de la funcién de ausitoria intema de la organizacion. 1, Determinar que la funcién de audito- tia interna ha sido asignada a una uni- dad separada dentro de la organizo- cién, baséndose en sus responsabilida- des segin las establezca el Estatuto de auditoria, 2. Revisar dicho estatuto para asegurar ue a la funcién de auditoria interna se le ha asignado Independencia en ia de- terminacién de las éreas en las cuales emprender revisiones de auditoria. 3. Determinar que este estatuto brinda una estructura para informar de los ha- llazgos de auditoria y de las recomenda- clones en una linea de comunicacién directa con la alta direccién. 4. Asegurar que el estatuto de Ia fun- cién de auditoria interna de la organizo- clén incluye declaraciones que estable- cen su autoridad para obtener acceso: limitado a registros manuales y automa- tics, a activos y al personal necesario para llevar a cabo sus revisiones. 5. Asegurar que las responsabliidades ‘signadas a a funcién de auditoria intema de la organizacion incluyen la revision peri6dica de todos los aspectos de las actividades del Departamento de informatica, y en concreto: a. gestion y administracién bb. desarrollo y mantenimiento de sistemas. c. explotacién de proceso de datos y apoyo a explotacién d._ servicios tecnicos. 1.5.2 Competencia técnica del personal de auditoria intema. * Objetive de Control. Los auditores responsables de Ia revision de las actividades del Departamento de Informética de la organizacion deberian ser técnicamente competentes y poseer los conocimientos/pericia_necesarios para efectuar eficaz y eficlentemente ales revisiones. * Directiva de Auditoria. Deben revisarse las actividades de ges- fién de la funcién de auditoria interna de la orgonizacién, a fin de asegurar la competencia técnica de los auditores asignados a revisiones de actividades del Departamento de Informatica y apli- b1-18 OBJETIVOS DE CONTROL, 1990. caciones informatizadas que se proce- san en el enfomo de sistemas de infor macién. 1. Asegurar que los auditores asignados alla revision de actividades del Departo- mento de Informatica y a las aplicacio- nes Informatizadas tienen suficiente preparacion 0 conocimiento de las Greas que se revisan para asegurar la Independencia tanto de sus trabojos ‘cuanto de sus hallazgos. 2. Si el personal disponible de auditoria intema carece de la competencia técni- ca suficiente para asegurar la indepen- dencia de sus trabojos y de sus ha- argos. deferminar que la direccion de la funcién de auditoria interna de la ‘corganizacién contrata_ a consultores infernos que poseen competencia sufi clente para ofectuar revisiones de las actividades y de las aplicaciones en ordenador de! Departamento de Infor- matic. PARTE | - 1. CONTROLES DE GESTION. 21 22 23 24 25 PARTE |: CONTROLES GENERALES Y DE APLICACIONES CONTROLES DE DESARROLLO, ADQUISICION ¥ MANTENIMIENTO DE SISTEMAS INFORMATICOS CONTENIDO CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO DE SISTEMAS INFORMATICOS. .... ++ ve HT METODOLOGIA Y RESPONSABILIDAD DEL CICLO DE VIDA DEL DESARROLL( DE SISTEMAS. .. 0-05-00 eee eer ee Pees oa 2.1.1. Metodologia de ciclo de vida del desarrollo de sistemas. 2.1.2. Papeles y responsabilidades. 2.13 Actualizacion del ciclo de vida del nuevo sistema. INICIACION DEL PROYECTO. 22.1 Definicién del proyecto. ....-- , 99 123 322 Patticipacién del departamento usuario en la Iniciacion del pro, YOCtO. eee eceeeee tresses errr Lb 212.3’ Composicion y responsablicades del equipo de proyecto... 12-4 3.0.4 Definicién de las necesidades de informacion. .. cee OS 22.5 Aprobacion del proyecto. .... ++ .+1s+ 125 ESTUDIO DE VIABILIDAD ...-. see eee ee ee eee ener ences veeeeene 126 2.3.1 Formulacién de cursos de acci6n alternatives. 126 23.2 Estudio de viobllidad tecnolégica 68 126 2.3.3 Estudio de viabilidad econémica 127 23.5 Aprobacién del proyecto. 128 2.36 Plan director del proyecto. 129 2.3.7 Control de costes. . .-- 129 FASE DE DISENO. 0. .0eee ence eeeer eres sees eeeeeeeeccee F210 2.4.1 Metodologia de deo... sss es : +. 1210 3.42 Definicién y documentacién de las especificacior . 2-10 3.43 Documentacién y definicion de especificaciones de entrada. +-2-1! 3.4.4 Detinicion y documentacién de especificaciones de ficheros. 12-11 3.45 Documentacién y definicién de especificaciones de proceso. 12-12 Especificaciones dé programas... ++... ++ 12-12 Disefio de Ia recogida de datos fuente. . . seve FRB Disefio de controles y seguridad. . aoe F213 2.49 Disefio de pistas de aucitoria. 1214 2.4.10 Aprobacién del disefio. . .. . , errr 12-15 2.4.11 Estandares de documentacién de programas. - 12-15 2.4.12 Plan de validacion. verificacion y pruebas. «... +--+ +++ 12-16 DESARROLLO E IMPLANTACION. ..... 00-05 ->> cece eee ree eees E26 2.5.1 Objetivos de programaci6n. ..... +. L217 25.2 Descripcién de la narrativa del programa. 12-17 25.3 Paquetes de logical de aplicacién. 12-18 124 PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION ¥ MANTENIMIENTO 26 27 25.4 Conratacion de programas de aplicacién a medida. 2.55 Manual de operaciones y mantenimiento, : 25.6 Manual de usuario. ys 2.57 Plan de Formaci6n. : 258 Estindares de prueba de programas. 259 Estandares de prueba de sistemas... » 25.11 Evoluaci6n de los resultados de los pruebes. 2.5.12 Plan de Conversion. ....- 2.5.13 Pruebas en Paralelo : 2.5.14 Prueba de aceptacién final. - EXPLOTACION Y MANTENIMIENTO. «0-0 e8e se e005rrse es 2.6.1 Procedimientos de control de explotacién. 2.62 Control de costes. .....-+ 7 263 Modificaciones al sistema, ...- +. sss sees 2.6.4 Re-evaluacion de las especificaciones de usuario, REVISION POST-IMPLANTACION. «5. 0+2-e0rececereseeesssnssss 1226 2.7.1 Plan de revision postimplantacion. Petts weve F227 2.72 Evaluacion de resultados. 0... +. e eee e see 1. 12-27 3 Evclvacion del cumplimiento de las especificaciones de usuario. 12-28 27.4 Andlisis de evaluacién coste-beneficio. «4... 1015s o so 12-28 25'5 Evaluacién del cumplimiento de los estindares de desarrollo. 12-28 29.6 Informe sobre los hallazgos de Ia revisi6n post-implantacion. . 12-29 b24i 2 CONTROLES DE DESARROLLO, ADQUI- SICION Y MANTENIMIENTO DE SISTEMAS INFORMATICOS. 2.1 METODOLOGIA Y RESPONSABILI- DAD DEL CICLO DE VIDA DEL DE- ‘SARROLLO DE SISTEMAS. El proceso que la organizacion sigue para el desarrollo, adquisicion ymantenl- miento de sistemas de informacion de- beria intentar alcanzar Ia eficacia del sistema, economia y eficiencia, integri- dad de los datos, proteccién de los recursos y cumplimiento con las leyes regulaciones. El empleo de una metodo- logia eficaz de ciclo de vida del desarro- ilo de sistemas deberia brindar a la alta direccién de la organizacion una garan- tia razonable de que dichos objetivos ser6n aicanzados. 2.1.1 Metodologia de ciclo de vida del desarrollo de sistemas. * Objetivo de Control. La alta direcci6n de Ia organizaci6n deberic publicar una declaraci6n escrita de politica estableciendo una metodolo- gia de ciclo de vida del desarrollo de sisternas, como medio para estructurar y controlar el proceso de desarrollo 0 ad- uisicion de sistemas informatizados, * Directiva de Auditoria, Debe revisarse la metodologia de ciclo de vida del desarrollo de sistemas de la corganizacién. 1. Revisar ol ciclo de vida del desarrollo de sistemas actuaimente en uso en la oiganizacion y determinar si se usa_un enfoque estructurado congruente con Conceptos y practicas generaimente o- ceptadas en el sector informatico. 2. Evaluar si cada fase de la metodolo- gia de ciclo de vida del desarrollo de sistemas en Ia organizaci6n tiene como resultado un producto acabado medible ‘que es sometida a una revision odecua- da y oprobacién antes de que el pro- 121 OBJETIVOS DE CONTROL, 1990. yecto pase a [a fase siguiente. Determ- nar si las especificaciones de planifica- cion de cada tase dentro de la metodo- logia estan claramente identificadas, 3, Determinar sila metodologia de cicio deo vida del desarrollo da sistemas en la organizacién brinda un mecanismo para controlar los cambios que pueden tener lugar a lo largo de la vida del proyecto. Revisar la metodologia para determinar la Importancia que en ella se concede gla seguridad y a los controles internos. 4, Deferminar 1a familiaridad, grado de formaci6n y experiencia que los plantilas tanto del Departamento de Informatica cuanto de los departamentos usuarios tienen en el uso de la metodologia de ciclo de vida de! desarrollo de sistemas de lo organizaci6n. 5, Determinar silos requisitos de la meto- dologia de ciclo de vida del desarrollo de sistemas de la organizacion son obl- gatorios u ofientativos y aprecian Ia fiexibilidad de! uso de ja metodologia bajo condiciones, cambios tales como por ejemplo en proyectos grandes y pequenios. Determinar si se permiten desviaciones de la metodologia, bajo que circunstancias puede esto ocuriir y si tales desviaciones han de ser docu- mentadas y probados. 6. Deferminar sila metodologia de ciclo de vida del desarrollo de sistomas de Io corganizaci6n incluye especificaciones de programaci6n y documentacion y estn- dores para usuarios, programadores. personal de desarrolio de sistemas. y para la plantilia de operaciones de! De- Partamento de Informatica. 7. Cerciorarse de si la metodologia de ciclo de vida del desarrollo de sistemas contempla la aplicacién de tecnologia. de boses de datos, el impacto de los telecomunicaciones, informatica de ‘usuario final’, y el empleo de lenguojes de Cuarla Generaci6n y de prototipos. asi como la seleccién e instalacion de productos de logical comerciales. PARTE.| - 2. CONTROLES DE DESARROLLO, 8, Deferminar sila metodologia de ciclo de vida del desarrollo de sistemas de fa organizacion est siendo realmente utill- zada en él desarrollo del logical. Apre- lar la adecuacion, actualizacion y adaptablidad a cambios tecnolégicos de la metodologia, para determinar el grado de riesgo que pueda exstir en el logical desarrollado con adhesion a fo misma. 2.1.2. Popeles y responsabilida- des. * Qbjetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas adoptada por Ia ‘organizacién deberia establecer los pa- peles, y responsabilidades del Departa- mento de Informatica, de los departa- mentos usuatlos, y de otros, en cuanto a plonificacion, desarrollo, revision, implan- faci6n y auditoria del producto final det proceso de desarrollo del sistema. * Directiva de Auditoria. Debe revisarse Ia asignacién de papeles y responsablidades en los diversas fases de la metodologia de ciclo de vida del desarrollo de sistemas de Ia organiza ci6n. 1. Determinar si \a asta direccién de la organizacién ha pubiicado un estatuto una declaracién escrita de politica que defina los papeles y responsabilidades en el proceso de desarrollo de sistemas. Los papeles definidos deberian incluir los do comité de planificacién o direcci6bn, los del departamento usuario, el equipo de proyecto, el grupo de garantia inter- na y el personal de operaciones del Departamento de Informatica. 2. Evaluar si cada fase de la metodolo- gia del ciclo de vida del desarrollo de sisternas de la organizacion permite a los grupos que participan en el proceso de desarrollo decidir a pasar a Ia fase si guiente o a modificar los objetivos © direccién del esfuerzo de desarrollo oa dar por terminado e! proyecto. 12-2 ADQUISICION Y MANTENIMIENTO 3. Determinar silos papeles y responsa- bilidades de equipo de proyecto estén claramente enunciados en la metodolo- gia del ciclo de vida del desarrollo de sistemas de la organizacion. Apreciar la ‘extension con la cual el director del pro- yecto puede tomar decisiones sobre el empleo de plontilla y otros recursos. la programacién de las actividades, las técnicas del desarrollo del sistema. 4, Determinar como han de ser selec- cionadios los representantes de los de- partamentos usuarios en los equips de proyecto y la extension de Ia participa cién prevista de los departamentos usuarios en el proyecto de desarrollo. Verificar que las responsablidades que les asigna son congruentes con sus ne- cesidades. &. Determiner \a extensién. bajo la metodologia de desarrollo de sistema de la organizacién de la participacién pre- vista de! grupo de garantia de calidad del Departamento de Informatica y del personal de Auditoria Interna dela direc- cién en el proceso ‘de desarrollo del sis- tema. 6. Revisar las disposiciones contenidas ‘en la metodologia del ciclo de vida de! desarrollo de sistemas de la organizaci6n ‘en cuanto a cosas tales como el conser- var una separacién de funciones, evitar conflictos de interés, y asegurar adecua- ‘dos controles de supervision. 2.1.3. Actualizacién del ciclo de vida del nuevo sistema. * Objetivo de Control. La metodologia del ciclo de vida del desarrollo de sistemas usada por la o1go- nizacion deberia revisarse periodicamen- te por la alta direccién de Ia organizo- ci6n para asegurar que sus disposiciones feflejan técnicas generalmente acepta- das hoy en dia y procedimientos. * Directiva de Auditoria. Deben examinarse los mecanismos de la organizacién para revisor la urgencia y adecuacién de las disposiciones de su metodologia de ciclo de vida del deso- rrolio de sistemas. 1. Determinar si existe un mecanismo para revisar periddicamente la adecua- Gién y vigencia de la metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion y examinar evalua- clones anteriores de dicha metodologia. 2. Determinar sise conserva un registto ‘escrito de las modificaciones 0 revisiones de las disposiciones contenidas en !a metodologia de ciclo de vida del desa- rrollo de sistemas de la organizaci6n, 3. Determinar, mediante entrevistas a los representantes de departamentos de sisternas, si estan satisftechos con Io for- ma en que la metodologia se usa ac- tuaimente. 2.2. INICIACION DEL PROYECTO. La metodologia de ciclo de vida del desarrollo de sistemas deberia permitirla participacién de los departamentos u- suarios en la Identificacién de la natu- raleza y 4mbito generales de un proyec- to de desarrollo de sistemas. Las especifi- caciones de informaci6n a cumplir por el sistema nuevo © modificado deberfan definise cuidadosamente por escrito y el desarrollo de un sistema propuesto de- beria aprobarse antes de que comience el proceso de desarrolio. 2.2.1 Definicién de! proyecto. * Objetivo de Control. La metodologia de ciclo de vida de! desarrollo de sistemas de la organizacion establecen Ia creacién de una defini cion claramente enunciada por escrito de la naturaleza y émbito de cada proyecto de desurrolio de sistema antes de que comience el trabajo en el pro- yecto, * Directiva de Auditoria. Deben examinarse las disposiciones esta- blecidas en la metodologia de ciclo de vida del desarrollo de sistemas de la or- 123 OBJETIVOS DE CONTROL, 1990. ganizacién para establecer por escrito el mbito y propésito de un desarrollo de sistema antes de que comience el traba- jo en el mismo. 1. Determinar que la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion establece |a presen- tacién por escrito de una solicitud de proyecto y que la misma incluye infor- maciones tales como: a. razones para abordar el proyecto. incluyendo: (1) enunciado del proble- ma a resolver), (2) una expresion de la necesidad de un sistema de informa- cién nuevo 0 modificado en términos de la mejora de la capacidad de la organizacién para aicanzar sus objet- vos), () un andlisis de las deficlenclas en los sistemas actuales aplicables), @ les oportunidades que se obten- rian por un aumento de ia economia 0 de a eficiencia de la operacisn), y © a necesidad. de control interno o de seguridad que seria satisfecha por ~ el proyecto b. el entorno del proyecto cc. el ambito del proyecto d, las restricciones al proyecto e. los beneficios a obtener mediante el proyecto f. quién es el patrocinador o usuario del proyecto. 2. Determinar que la metodologia de Ciclo de vida del desarrollo de sistemas de la organizacién establece que las peticiones de proyecto sean revisadas en cuanto a su congruencia con Ia planificacion aprobada del Departa- mento de Informatica 0 con el pian para ‘ol ano en curso de! comité de direcci6én. 3. Deferminar, revisando los registros referentes a proyectos de desarrollo de sistemas de informacién, seleccién, quo: las peticiones se prepararon, se reviso- ron, y aprobaron de contormidad con la PARTE | < 2. CONTROLES DE DESARROLLO, ADQUISICION ¥ MANTENIMIENTO metodologia de ciclo de vida del desa- rrollo de sistemas. 2.2.2. Participacién del departa- mento usuario en {a iniciacién del pro- yecto. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacton deberia establecer la participacién por parte de la direccién del departamento Usuario afectado en la definicién y auto- rizacién de un proyecto de desarrollo 0 modificacién de un sistema de Informa- cién. * Directiva de Auditoria. Deben revisarse las disposiciones en Ia metodologia de ciclo de vida del desa- trollo de sistemas de Ia organizacion en cuanto a Ia participacién por la direc- clén y del departamento usuario afecta- do en la definicién y autorizacién de una modificacién o desarrollo de sistemas de informética. 1. Revisar los actas del comité de pla- nificacién © de direccién del Departa- mento de Informatica y los planes relat- ‘vos a proyectos escogidos para determi- nar la extension de la participacién de los departamentos usuarios en el trabajo de los comités y en general en el proce- so de definir y autorizar el desarrollo o modificaciones de sistemas intormaticos. 2. Revisar los presupuestos de departa- mentos usuarios seleccionados para identificar la asignacién de tiempo por miembros de {a piantila del departa- mento a los proyectos de modificacion © desarrollo de sistemos significativos de! Departamento de informatica. 2.23 Composicién y respon- sabilidades del equipo de proyecto. + Objetive de Control. La metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacin deberia especificar las bases para asig- nar a Individuos de Ia plantilla coma 12-4 miembros del equipo de proyecto y definir las responsabllidades de los distin- tos miembros del proyecto. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia da ciclo de vida del deso- rrollo de sistemas de la organizacién para asignar a Individuos como miem- bros de equipos de proyectos y definir sus responsabllidades. 1. Identificar, para proyectos seleccio- nados de desarrollo o modificacién de sistemas de informacién, Ia persona a cargo del proyecto, los nombres de todos los miembros del equipo de pro- yacto y sus responsabilidades. 2. Evaluar los antecedentes y las cuall- ficaciones de estos individuos como una medida do lo adecuacién de su asigna- ci6n a tareas especificas de proyectos bajo Ia metodologia de ciclo de vida del desarrollo de sistemas de la organiza- ion 3. Determinar si la direccién de los departamentos usuarios implicados en el desarrollo 0 modificaciones de proyectos significativos de sistemas informaticos ha nombrado a ingividuos de sus depor- ‘tomentos para participar en los equipos pertinentes del proyecto y evaluar si ales personas tienen: a. una comprensién profunda de las necesidades de informacién del de- portamento a ser sotisfechas por el producto final planificado en este esfuerzo b. la habllidad para trabajar con los otros miembros del equipo de proyec- to ¢. la misma comprension del ambito y objetivos del proyecto que tienen los demés miembros del equipo. 2.2.4 Definicién de las neces!- dades de informacién. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacién deberia establecer que las necesidades de informaci6n a ser satistechas por e! sistema actual o el nuevo 0 modificado deberfan ser claramente definidas antes de que el se apruebe un proyecto de desarrollo 0 modificaci6n. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del desa- trollo de sistemas que requieren que las necesidades de informatica a ser satisfe- has por el sistema actual o el propuesto ‘© modificado sean definidas antes de que se apruebe un proyecto de desarro- lo. 0 modificacion. 1. Cerciorarse, para proyectos seleccio- nados de desarrollo 0 modificacién de sisternas de informacién de que se han ‘cumplidos los requisitos de la metodolo- gia de ciclo de vida del desarrollo de sistemas de la organizaci6n, respecto a documentaci6n. En particular, asegurar que: a. las descripciones del sistema ac- tual son adecuadas para servir de base para el estudio de las necesi- dades del sistema propuesto, nuevo 0 modificado b. que se han identificado claramen- te aquellos aspectos del sistema ac- tual que serfan cambiados por el se- tian cambiados por el sistema pro- puesto c. que el Departamento de Infor- mética ha evaluado, en cuanto a cuan completo son, a su congruencia, y ala viabilidad del tratamiento de la informacién dichas especificaciones de informacién d, que esas especificaciones de in- formacién han sido revisadas y apro- badas por la direccion de los departa- 12-5 OBJETIVOS DE CONTROL, 1990. mentos usuarios implicados en el pro- yecto de desarrollo. 2.2.5 Aprobacién del proyecto. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizaci6n deberia contener disposiciones para ja ‘aprobaci6n por miembros asignados de 1a direcci6n del trabajo llevado a cabo en cada fase del ciclo antes de que comience el trabajo en la fase siguiente. * Directiva de Auditoria. Debe revisarse lo dispuesto por la meto- dologia de ciclo de vida de! desarrollo de sistemas de la organizacion en cuan- fo a la aprobacién por miembros desig- nados de la diracci6n del trabajo ejecu- tado en cada fase del ciclo antes de que comience el trabajo en Ia fase si- guiente. 1. Deferminar, mediante una revision de los registros referentes a proyectos de desarrollo 0 modificacion de sistemas informéticos seleccionados, que el equi po de proyecto ha preparado un infor- me escrito cubriendo los aspectos enun- Ciados en Ia propuesta el proyecto y definiendo las especificaciones de infor- mética a ser satisfechas por el productor final del proyecto. 2. Verificar para proyectos de desarro- ilo 0 modificacién de sistema de Infor- mética seleccionados, que Ia direccién el Departamento de Informatica y de los departamentos usuarios han revisado los informes de los equipos de proyecto relativos a las especificaciones de infor- macién a ser satisfechas por los produc- tos finales de estos proyectos. Ademés, vetificar que ambos han dado aproba- cin escrita para que comience el tra- bojo en la siguiente tase del proyecto. PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO 2.3. ESTUDIO DE VIABILIDAD Una metodologia de ciclo de vida de! desarrollo de sistemas en cualquier orgo- nizacion deberfa establecer, para cada proyecto o propuesta, que se elabore un estudio tecnolégico de viabllidad en et ‘cual se formuien formas altematives de aicanzor los objetivos del proyecto o- comparades de un anéiisis de coste - beneficio - de cada alternativa contem- plada (entre los temas a considerar esté la posibilidad de una alternativa nula y \a viabilidad de una decision altemativa entre desarrollar 0 comprar). Cuando se toma la declsién de seguir adelante en el trabajo con el tema propuesto, debe producirse un plan director del proyecto, por escrito, 2.3.1 Formulacién de cursos de accién altemativos. + Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera determinar que se analicen cursos de accién alternatives que satisfo- gan las especificaciones de informacion establecides para el sistema propuesto, nuevo 0 modificado. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacion que exigen que se analicen cursos de accion ‘altemativos que satisfagan las especifi- caciones de informacién establecidas para el sistema propuesto, nuevo o modificado. 1. Cerciorarse, para proyectos selec- clonados de desarrollo o modificacién de sistemas de informacion, de que el equipo de proyecto ha analizado cursos de accién alternativos, y que el informe 126 del equipo identifica. para Io alternativa seleccionada como més viable, las: a. razones para seleccionar o recha- zar cada una de las altemativas const- deradas b. ventajas y desventojas de Ia alter- nativa selecclonada 2.3.2 Estudio de viabllidad tec- nolégica * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion debiera determinar que se efectue un ‘examen de la viabilidad tecnolégica de cada cltemativa que satisfaga las espe- Cificaciones de informacion establecidas para el sistema propuesto, nuevo 0 modificado. * Directiva de Auditoria. Deben revisarse las disposiciones de Ia metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacién para que se efectte un examen de Ia viabilidad tecnolégica de cada alter. nativa que satisfaga las especificaciones de informacién establecidas para el sistema propuesto, nuevo o modificado, (El Auditor Informatico debiera recono- cer que, en alguno casos, Ia viabllidad operativa de ia altemativa propuesta para un proyecto concreto puede llegar ser un gran problema. Esto puede ser especialmente cierto cuando vayan a producirse cambios en los cometidos 0 dependencia del personal. Cuando fiene lugar una situaci6n asi, la metodo- logia de ciclo de vida del desarrollo de sistemas de la organizacién debiera disponer un examen por separado de ia viabllidad operativa de tal aiternativa). 1. Revisar, para proyectos seleccionados de desarrollo de sistemas de informa- cién, al informe preparado por el equipo de proyecto sobre la viabllidad tecnol6- gica de cada una de jas altemativas para satistacer las especificaciones de informacién establecidas. Evaluar lo forma en que dicho informe ha tratado temas tales como: a. las necesidades y dsponibilidad de equipos b, las necesidades y disponibilidad de logical c. las necesidades y disponibiidad de matetial y logical de comunicacio- nes d._restricciones espaciales y tempo- tales vélidas Implicitas en las solicitu- des de Informacién de los departa- mentos usuarios, y la forma de satista- cerlas e. Ia viobllidad operativa, por ejem- pio, si el nuevo proyecto encoja on 6! fentorno actual de material, logical y comunicaciones de la organizacion f. consideraciones legales relatives a la transferencia de tecnologia o da- tos, de Gmbito nacional o internacio- nal restricciones regiamentarias relatl- vas a 1a utilzacion de tecnologia y a a forma de conseguir la conformidad © aprobacién de las autoridades regu: Jadoras pertinentes. 2. Vetificar, para proyectos nuevos o de modificacién de sistemas informéticos, seleccionades, que la direccion de los dopartamento usuarios afectados y la del Departamento de Informatica sean puesto de acuerdo sobre la viobilidad tecnolégica del método seleccionado para salisfacer las necesidades de infor- fnacion establecidas para el proyecto, én el marco de la metodologia de ciclo de vida del desarrolto de sistemas de la organizaci6n. 2.3.3 Estudio de viabilidad eco- némica * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera requerir, para cada proyecto nuevo 0 de modificacion de sistemas informéticos.que & efectue un anélisis 127 OBJETIVOS DE CONTROL, 1990. coste-beneficio, que contemple los costes y beneficios asoclados a cada ‘ltemativa considerada para satisfacer fas necesidades de Informacion osta- iplecidas para el proyecto * Directiva de Auditoria. Deben ravisarse las determinaciones de la metodologia de ciclo de via del ‘desarrollo de sistemas de la organizacion que disponen que e analicen los costes Y beneficios de cada aiternativa cons derada para el proyecto. 1. Revisar para proyectos de desarrollo y/o modificacién de sistemas de infor- macion seleccionados, el resumen de costes del sistema actual, al igual que los costes estimados para cada una de las ‘alternativas consideradas para satisfacer Jas especificaciones de informacion esta~ blecidas pare el proyecto, a fin de cer- Clorarse de que todas los costes signif Cativos se han incluido en el sumario. En concreto determinar si: a. _ os costes presentados cubren todas las tases del ciclo de vida de desarrollo de sistemas para dicho sis- tema b. silos costes estimados para cada Gitemnativa considerada incluyen to- das las mejoras necesarias en material y logical pora apoyar esa atternativa concreta, al igual que los costes en que pueda ser necesario incurrir para formaci6n, preparaci6n y entrada de datos, conversion, y aceptacién del sistema, y costes asociados cuando proceda. 2. Revisar para proyectos de desarrollo © modificacion de sistemas selecciona- dos, el resumen de los beneficios estima dos para cada alternativa considerada para satisfacer las especificaciones de informacion que han sido establecidas para el proyecto 3. Verificar que los beneficios han sido Guantificados siempre que era posible y que no sé ha incluido ningtn beneficlo no cuantificable en el resumen. PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO 4, Verificar para proyectos de desarro- | jlo © modificaci6n de sistemas de infor- maci6n seleccionadas que el anéiisis de Coste y beneficios asociados con cada ‘ltemativa considerada para satisfacer las espectficaciones de informacion con- templa su impacto sobre los requisitos de seguiidad, Intimidad y control intemo que han sido establecidos para el pro- yecto de forma general. 6. Verificar para proyectos de desarro- lo 0 modificacion de sistemas seleccio- nados, que las direcciones de los depar- tamentos usuarios afectados y [a del Departamento de Informatica se ha puesto de acuerdo sobre los costes Beneficlos asociados a la altemativa seleccionada para satistacer as especifi- caciones de informacion. 23.4 Informe del andlisis de riesgo. * Objetivo de Control. la metodologia de ciclo de vide del desarrollo de sistemnas de la organizacion deberia establecer en cada proyecto propuesto de desarrollo © modificacion de sistema de informacion. la confec- cion de un andlisis de los rlesgos de seguridad, de los controles internos ne- cesarios y de las salvaguardias viables para reduciro eliminar dichos vulnerabili- dades. * Directiva de Auditoria. Deben revisarse las disposiciones del ciclo de vida del desarrollo de sistemas de la organizacién que exigen que. para cada proyecto propuesto, se analicen Jos riesgos de seguridad, los controles internos necesorios y las salvaguardios viables para reducir o eliminar tales vulnerabilidades. 1, Revisar, para proyectos de desarrollo (© modificacién de sistemas de informa cién seleccionados, Ia lista de necesido- des de control intemo y de vulnerabil- dades de seguridad que se ha identifi- 128 cado para dichos sistemas. Incluir cud uier lesgo conocido en otros sistemas y Gpreciar si el proceso de determinar foles vulneroblidades rest6 atencion a: a. todos los aspectos de la aplico- Cin incluyendo cosas tales como el empleo de enlaces de telecomuni- caciones y las disposiciones pertinen- tes de plan de contingencia b. lanaturaleza y magnitud de cada una de las vulnerabildades c. el valor y sensibilidad de todos los ficheros de datos y otros activos de informacién a incluir en el sistema. 2. Verlficar, para proyectos de desorro- ilo 0 modificacién de sistemas de infor macién selecclonados, que en el diseio fempleado en el proyecto se incluyeron salvaguardias para. reducir los rlesgos identificados en dichas sistemas. 3. Determinar, mediante entrevistos. que la direccion de los departamentos usuarios, el individuo responsable de la seguridad de la informacion, los aucito- Tes informaticos, y otras personas ade- cuadas participarén en-los andlisis de tiesgo relacionados con estos proyectos. Cerciorarse de que quedaron satisfechos con cual completes y razonable era el andlisis, sus hollazgos y recomendacio- nes. 2.3.5 Aprobacién del proyecto. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion deberia establecer, que en cada pro- yecto propuesto, la gta direccion revise los informes de los estudios de viablidad portinentes, decida si seguir adelonte no con el proyacto. e identifique una de las alternativas examinadas en tales estudios como base para el trabajo det equipo del proyecto. * Directiva de Auditoria. Deben revisarse las disposiciones de metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacién que exigen, para cada proyecto propuesto que Ia alta direccién de Ia organizacion revise los estudios de viobllidad pertinen- tes, determina sise debe seguir adelante con el proyecto e identifique una de las altemativas examinadas en tales estu- dios. 1. Deferminar para proyectos de desa- rrollo 0 modificacién de sistemas de in- formaci6n seleccionadas que los Infor- mes del estudio de viabilidad exigidos por la metodologia de ciclo de vida del desarrollo de sistemas de la organizo- ci6n, se prepararon y presentaron para revision por Ia alta direcci6n. 2. Determinar que dichos informes fue- ton revisados por Ia alta direccién y empleados como base para una deci sién escrita acerca de si seguit adelante ono con el proyecto. 2.3.6 Plan director del proyecto. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion. deberia establecer para cada proyecto aprobado, que se elabore un plan direc- tor del proyecto, adecuado para man- tener control sobre el proyecto alo largo de toda su vida. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclos de vida de desa- rrollo del sisterna de la organizacion que exigen para cada proyecto aprobado que establezca un plan director del proyecto. 1. Determinar, mediante revision de los registros de proyectos de desarrollo o modificacién de sistemas de informacion relacionados que se establecié un plan director de! proyecto. 2, Determinar que el nuevo plan direc- tor inclula un calendario completo de descomposicién del trabajo en activida- 129 OBJETIVOS DE CONTROL, 1990. des de proyecto, identificaba los puntos pertinentes de pruebas de aceptacion a To largo de la vida del proyecto, y defi- nia los procedimientos de evaluacion y ‘aprobacién requeridas en cada uno de dichos puntos. 3. Deferminar que el plan director se uso para efectuar el requerimiento del pro- reso del proyecto y que el plan director satisfacia lo dispuesto por la metodolo- gia de ciclo de vida del desarrollo de sistemas de la organizocion. 2.3.7 Control de costes. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizaci6n deberia establecer, para cada proyecto de desarrollo o modificacién de sistemas de informacién aprobado, que se esto- blezca un plan director del proyecto que incluya un método para efectuar el control de los costes en que incurra a lo largo de la vida del proyecto. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del deso- rollo de sistemas de la organizacién que ‘exigen que el plan director del proyecto creado para cada proyecto de desarro- lo 0 modificacién de sistemas de infor- maci6n aprobado, incluya un método para efectuar el control de los gastos en que se incurra a lo largo de Ia vida del proyecto. 1. Revisar para proyectos de desarrollo ‘© modificacién de sistemas de informa- cién aprobados, los informes sobre los costes en que se ha incurrido en relacién con el trabajo realizado en el proyecto. 2. Identificar los componentes de tales Costes como tiempo de maquina, horas de empleadios y suministros y examinar {0s justificantes de dichos componentes de costes tales como resumenes de tiempo de maquina usados por el equi po del proyecto o informes de tiempo de empleados individuales. PARTE 1 - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO 3. Determinar si esta informacion de costes es completa y correcta. 4, Deferminar para proyectos de deso- rrollo o modificacién de sistemas de in- formacion seleccionades, si los informes de costes del proyecto exigidos por fa metodologia de ciclo de vida del desa- rrollo de sistema de la organizacion so prepararon, distribuyeron, revisoron, ¥ caprobaron oportunamente. 2.4 FASE DE DISENO. La metodologia de ciclo de vida del desarrollo de sistemas dela organizacion debiera establecer para cada proyecto de desarrollo 0 modificacion de sistemas de informacion, que las especificaciones del sisterna se incorporen adecuada- mente a las especificaciones de diseno © del sistema. Debiera usarse una meto- dologia de disefio para estructurar et desarrolio de las especificaciones de entradas, salidas, ficheros, y tratamien- tos, que describen la solucion fisica a las especificaciones del sistema, Esta meto- dologia de disefio debiera también emplearse para especificar los docu- mentos fuente, los mecanismos de con- trol, las coracteristicas de seguridad y las pistas de auditoria a incluir en el sistema. 2.4.1 Metodologia de disefio * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacién, debiera establecer que se seleccione un, procedimiento adecuado para la crea- cl6n de las especificaciones de disefio de cada proyecto de desarrollo o modi- ficaci6n de sistemas de informacién. + Directiva de Auditoria. Deben revisarse las provisiones de la metodologia de ciclo de vida del desa- rrollo de sistema de la orgonizacién que ‘exige que se selecciones un procedi- miento adecuado para la creacién de las especificaciones de disefio en un proyecto de desarrollo 0 mosificacién de sistemas de informacion. 12-10 1. Determinar, para proyectos de deso- rrollo 0 modificacién de sistemas de In- formacién representativos, el proced- miento de disefio escogido para el siste- ma (normaimente éste seré uno de los s- guientes: ciclo de vida, estructurado, base do datos, esqueleto, o protatipo). silos miembros del equipo de proyecto estén familiarizados con - 0 ‘entrenados en - el empleo de este pro- cedimiento y sel mismo esté slendo eft- cazmente usado en el desarralio de las especificaciones de disefio del sistema. 2. Determinar, para proyectos de desa- trollo © modificacién de sistemas de in- formacién representativos, si los produc- tos finales creados mediante el empleo del procedimiento de diserio selecciona- do para el sistema satisfacen las especifi- caciones del sistema pertinentes. 2.4.2 Definicin y documenta- clén de las especificaciones de salida. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera establecer que se seleccione un procedimiento adecuado para crear las especificaciones de salida de cada pro- yecto de desarrollo 0 modificacion de sistemas de informacion. * Directiva de Auditoria. Deben revisarse las provisiones de lo metodologia de ciclo de vida del deso- rrollo de sistemas de Ia organizacién que exigen que se seleccione un procedi- miento adecuado para crear las espect- ficaciones de salida de un proyecto de desarrollo o modificaci6n de sistemas de informacién. 1, Revisar, para proyectos de desarro- lo 0 modificacibn de sistemas de infor- macién seleccionados. si las especifica- ciones de salida que se han establecido son adecuadas, y determinar si son conformes con la metodologia de ciclo de vida de! desarrollo de sistemas de 1a organizacién. 2. Revisar las especificaciones de sall- da para proyectos de desarrollo o mod- ficacién de sistemas de Informacién selecclonados, y deferminar lo adecua- do de las provisiones en cuanto a: ‘a. contenido y formato de los infor- mes preparados b. autorizacion de los usuarios que han de recibir los informes c. petiodo de retencibn de los infor- mes d. provisiones de pistas de auditoria ‘0 gestion e. periodo de retencién de ficheros. 3. Determinar que las especificaciones de salida retenidas para proyectos de desarrollo 0 modificacién de sistemas de informaci6n seleccionadas, brindan alos usuarios del sistema la capacidad de asegurar © controlar que los datos son completes, exactos y autorizados. 2.4.3 Documentacién y defini- cién de especificaciones de entrada. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera establecer que se seleccione un procedimiento adecuados para la crea- cin de las especificaciones de entrada, ‘en cada proyecto de desarrollo o modi- ficacién de sistemas de informacién * Directiva de Auditoria. Deben revisarse las provisiones de meto- dologia de ciclo de vida de! desarrollo de sistemas de la organizacién que exigen que se seleccione un procedt- miento adecuado para crear las especi- ficaciones de entrada en un proyecto de desarrollo 0 modificaci6n de sistemas de informacié6n. 1. Revisar, para proyectos selecclona- das de desarrollo © modificacion de sis- temas de informacién. la adecuacion de 1201 QBJETIVOS DE CONTROL, 1990. las especificaciones de entrada que se han establecido y deferminar si son conformes con al metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion. 2. _ Revisar las especificaciones de ‘entrada para proyectos selecclonados de desarrollo o modificaci6n de sistemas de informacién y determinar cuan ade- cuadas y razonables son las disposicio- nes en cuanto a: 1. los especificaciones de seguridad y de proteccién de datos relaciona- dos con Ia intimidad b. las medidas de seguridad y de proteccién de datos relacionadas con la intimidad c. las regias de definicion y autoriza- cién de transacciones d. los procedimientos para el esta- blecimiento de totales de control. 3. Deferminar, para proyectos seleccio- nados de desarrollo o modificacién de sistemas de informaci6n si tas definicio- nes escritas de entradas han sido revi- sadas y aprobadas por escrito por la direccién de! departamento usuario. 2.4.4 Definicibn y documenta- cién de especificaciones de ficheros. * Objetive de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacién debiera disponer que se seleccione un procedimiento adecuado para la defini- cin de las espectficaciones de formato y organizacién de ficheros para cada proyecto 0 de desarrollo 0 modificacion de sistemas de informacion. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del desa- rollo del sisterna de la organizacién de ficheros para cada proyecto de desarro- PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO ilo 0 modificacién de sistemas de infor- macién. Deben revisarse las disposiciones de la metodologia de ciclo de vida del deso- trollo de sistemas de la organizacién que exigen que se seleccione un procedi- miento adecuado para la creacién de las especificaciones de formato y organ- zacion de ficheros para un proyecto de ‘desarrollo o modificacién de sistemas de informacion. 1. Determinar, para proyectos seleccio- nados de desarrollo o modificacién de sistemnas de informacién, la adecuacion de las definiciones de formato y organ zacién y su conformidad con las dispost- clones de la metodologia de ciclo de vida del desarrollo de sistemas. Si se necesitan ficheros de base de datos deferminar si la definicibn cubre las relaciones légicas, fisicas y otras estructu- rales de los datos, dependencias de los conjuntos de datos, especificaciones de almacenamiento de datos y cualesquie- ra especificaciones especiales necesa- tias para asegurar la proteccién de la jimidad. 2. Determinar, para proyectos seleccio- nados de desarrollo o modificacion de sistemas de informaci6n si los adminis- tradores de bases de datos de Ia organi- zaci6n parliciparon en el establecimien- to de las definiciones escritos de formato y organizacion de ficheros. 3. Determinar, para proyectos seleccio- nados de desarrollo 0 modificacién de sistemas de informacién la adecuacion de las definiciones de formato y organi- zacién de ficheros, de sensibilidad de contenido de los datos. y periodos de retenci6n de ficheros. 4. Determinar, para proyectos seleccio- nados de desarrollo o modificacién de sistemas de Informacién, si las definicio- nes escritas de formato y organizacién de ficheros han sido revisadas y aproba- das por la direccién de los departamen- tos usuarios afectados. 12.12 2.45 Documentacién y defini- cién de especificaciones de proceso. * Objetivo de Control. La metodologia de ciclo de vida de! desarrollo de sistemas de a organizacion deblera disponer que $9 selecciones un procedimiento adecuado para definir las especificaciones de los pasos de proceso de datos para cada proyecto ‘de desarrollo o modificaci6n de sistemas de informacién. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del desa- rollo de sistemas de la organizacién que exigen que se seleccione un procedi- miento adecuado para crear las especi- ficaciones de pasos de proceso de datos para _un proyecto de desarrollo 0 modificacién de sisternas de informa- ibn. 1. Revisar, pora proyectos selecciona- dos de desarrollo 0 modificacion de sis- temas de informacién la exactitud, vall- dacién, oportunidad en el tiempo y flex- bllidad de las especificaciones de pasos de proceso que han sido establecidas y determinar si son conforme con la meto- dologia de ciclo de vida de! desarrollo de sistemas de la organizacién. 2. Deferminar, para proyectos seleccio- nados de desarrollo o modificacién de sistemas de informacion si las especifi Caciones de pasos de proceso de datos escritos han sido revisados y aprobadas por la direcci6n de los departamentos Usuarios afectados. 2.4.6 Especificaciones de pro- gramas. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas debiera exigit que se preparen espectficaciones escritos detalladas de programas de desarrollo 0 modificacién de sistemas de informa- cién. * Directiva de Auditoria. Deben revisarse las disposiciones de Ia metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacién que exigen que se preparen espectficaciones de programas detaliadas escritas para cada proyecto de desarrollo o modifica- Clones de sistemas de Informaci6n. 1. Revisar, para proyectos selecciona- dos de desarrollo o modificacion de sis- temas de informacién la adecuacién de las especificaciones de programas que han sido establecidas y determinar si son claras, congruentes y completes y de conformidad con la metodologia de Ciclo de vida del desarrollo de sistemas de la organizacion. 2. Revisar, para proyectos selecciona- dos de desarrollo 0 modificacion de sis- temas de informacién, cuan razonable @s la logica del programa que se ha definido mediante un examen de los fiujogramas, tablas de decision, onarrati- vas pertinentes. 2.4.7 Disefio de la recogida de datos fuente. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacién debiera exigir que se especifiquen me- canismos adecuadas para la entrada de informacién para cada proyecto de desarrollo 0 modificacién de sistemas de informaci6n. * Directiva de Auditoria. Deben revisarse las disposiciones de fa metodologia de ciclo de vida del desa- rrollo de sistemas de la organizacién que exigen que se especifiquen mecanismos adecuados para la entrada de informa- cién para cada proyecto de desarrollo (© modificacin de sistemas de informa- ci6n. 1. Revisar, para proyectos selecciona- dos de desarrollo o modificacién de sis- temas de informacion, los mecanismos: especificados de recogida de datos fuente para determinar sisu disefio facili- $a una entrada de Inforrnacién exacta y 12-13 QBJETIVOS DE CONTROL, 1990. si dichos disefios han sido aprobadas por la direccién de los departamentos usud- trios afectados. 2, Determinar, para proyectos seleccio- nados de desarrollo o modificacién de sistemas do informacién, si las disefios de ‘cualesquiera formularios que hayan sido especificados para la recogida de infor- maci6n, establecen controles tales Co- mo un encasilado exacto para las anotaciones, numeracién previa de los documentos, y autorizaci6n indepen- diente de las transacciones. 3. Determinar, para proyectos seleccio- nados de desarrollo © modificacién de sistemas de Informacién silos disefios de cualesquiera procedimientos de entrada en Iinea de la informacién establecen formatos de pantalla. que emplean men- sojes y procedimientos do entrada que facilitan la exactitud y si brindan rutinas de correccion para corregir los errores 2.4.8 Disefho de controles y se- guridad. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera exigir se especifiquen mecanis- mos adecuadas paraasegurar|a integr- dad de los datos almacenados y trata- dos por un sistema de informacién y para salvaguardar los recursos del siste- ma, en cada proyecto de desarrollo 0 modificaci6n de sistemas de informa- cci6n. * Directiva de Auditoria. Deben revisarse las disposiciones de Ia metodologia de ciclo de vida del desa- rrollo de sistemas de la organizacién que exigen mecanismos adecuodos para asegurar la integridad de los datos alma- enados y procesados por un sistema de informacion para salvaguardar los recur- s0s del sistema para cada proyecto de desarrollo o modificacion de sistemas de informacion, 1. Revisar, para proyectos selecciona- dos de desarrollo 0 madificacién de sis~ PARTE | - 2. CONTROLES DE DESARROLLO, [ADQUISICION Y MANTENIMIENTO- temas de informacion, las medidas de | Gontol de integridad y mediacion de accesos en sus ‘especificaciones ¥ eva- fuarias respecto de una metodologio qaecuada de disefio de controles © fevaluacién de seguridad. 2, Determinar, para proyectos seleccio- nados de desarrollo o modificacion de sistemas de Informacion: ‘a. Slentos especificaciones de dise- fho se han inciuido, en cada punto critico del sistema, controles adecuc- dos b. que se ha efectuado el anélisis coste-beneficio para dichos controies c. que se ha establecido una distin- cién adecuada entre el uso de con- froles preventivos y controles detecto- res d. si se han establecide controles comectores donde y cuando era ade- cuado. 3. Determinar, para proyectos seleccio- nados de desarrollo o modificaci6n. sla funcién de audiforia interna ha evalua- do la adecuaci6n de los controles inclu dos en las especificaciones de disefio del sistema. 4. Determinar, para proyectos seleccio- nados de desarrolios o modificacion de Sistemos de informacion que afectan a fransacciones © datos sensibles. si el oficial de seguridad de la informacion de la organizacién ha revisado y apro- bados. Los controles de integridad y las medidas de mediocin de accesos incluidas en sus especificaciones, espe- Cialmente en términos de su efecto en ta taduecion o eliminacion de los rlesgos asociados con Ia operacion del sisterna. 5, Determinar, para proyectos seleccio- Fados de desarralia o modificacion de sistemas de Informacion, si los controles de integridad, si los controles de Integr dad y las medidas de mediacion de accesos incluidas en sus especificacio- 12.14 nes han sido definidas con detalle suf Clente para faciltar que puedan ser probadas adecuadamente. 2.49 Disefo de pistas de audi- toria. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo del sistema de la organizacion Gablero exigir que se especifiquen me- Canismos adecuados de pistas de auc toria en cada proyecto de desarrollo o modificacion de sistemas de Informa- clon. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del deso- rrollo de sistemas de la organizocion que exigen que se especifiquen pistas de ‘qudltoria adecuadas para cada proyec- to de desarrollo o modificaci6n de siste- mas de informacién. 1. Revisar, para proyectos selecciona- dos de desarollos 0 modificacion de sistemas de Informacion, las pistas de ‘quditorfo especificadas para determinar sisu diseho es adecuado, especiaimente fen términos de Ia Inclusion de mecanis- mos tanto autométicos cuanto normales y de su efectividad para segui la pista. o jas transacciones desde el punto de origen hasta los totales de control pert nentes y desde éstos hacia atrés hasta e! punto de origen. 2. Revisar, para proyectos selecciona- dos de desarrollo o modificacién de sis- temas de informacion, la adecuacién de las medidas establecidas para la integri- dad y seguridad de las pistas de audito- tia en las especificaciones de diseno. 3, Determinar, para proyectos seleccio nados de desarralio © modificacion de Sistemas de Informacion, sla funcion de ‘cuditoria interna ha evaluado lo ade- cuacién de las pistas de auditoria in- Cluldas en ios especificaciones de disenio del sistema. 2.4.10 Aprobacién del disefio. ‘ * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera exigir que las especificaciones de disefio de todos los proyectos de desarrollo o modificacién de: sistemas de informaci6n sean revisados y aprobadas por la direccién del departamento de informatica, porla de los departamentos usuarios afectados y. cuando proceda por la alta direccién de la organizacion. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacion que exigen que las especificaciones de dise- fio de todos los proyectos de desarrollo ‘© modificaci6n de sistemas de informa- cin sean revisados y aprobadas por Ia direcci6n del departamento de informé- fica, la de los departamentos usuarios afectados, y cuando proceda por la ‘alta direcci6n de la orgonizacion. 1. Determinar, para proyectos seleccio- nados desarrollo o modificacion de siste- mas de informacién, silos especificacio- nes de disefio han sido revisadas y apro- badas por la direccién del departomen- to de informatica, la de los departamen- tos usuarios afectados, y cuando proce- da por la alta direccién de la organiza- cién. 2. Determinar que todas las cuestiones que surgieton durante esta revision y ‘aprobaci6n han sido resuettas antes del comienzo del trabajo en|a fase siguiente del proyecto (si en los proyectos selec- cionados para revision por el auditor quedaran cuestiones sin resolver, lo naturaleza de las mismas y su significado debieran ser objeto de comentario). 2.4.11 Estandares de documen- tacién de programas. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas dela organizacion debiera incluir estandares de documen- OBJETIVOS DE CONTROL, 1990. tacion de programas aprobados por el comité de planificaci6n co el comité de direccién del departamento de informa fico, comunicados a a piantila del departamento y cuya aplicacion se Viglia para asegurar la documentacion ‘creada durante la ejecucién de proyec- tos de desarrollo 0 mantenimiento de sistemas de Informacion rehace de con- formidad con tales estandares. * Directiva de Auditoria. Deben revisarse los esténdares de docu- mentacién de programas que formen parte de la metodologia de ciclo de Vida de! desarrolio de sistemas de la organizacion y los medios que se em- plean para asegurar su cumplimiento 1, Obfener una copia de los estan- dares de documentacion de programas de la organizacién y deferminar si di- hos estndares han sido aprobados por el comité de planificacién o el comité de direccion del departamento de Infor mética, si son apropiados en términos del material, sisternas operatives. y len- guajes de programacién en uso en Io ‘organizacién ysl aprovechan plenamen- fe las ventojas de las buenas précticas en ingenieria de logical. 2. Determinar, mediante entrevistas ‘con los individuos implicados, y median- te una revision de ia documentacion de proyectos seleccionados de desarrollo y modificacién de sistemas de informa- cién, silos estandares de programacion incorporados a la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion se han comunicado a la plantila del departamento de informati- cay sise cumplen. 3. Revisar la documentacion relative a proyectos seleccionados de desarrollo y modificacion de sistemas de informacion y determinar sila direccién del departa- mento de informatica ha revisado dicha documentacién para confirmar su ade- cuacién y su cumplimiento con los @s- fandares de documentacién de progra- mas integrantes de la metodologia de ciclo de vida de! desarrollo de sistemas de la organizacion. PARTE I - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO- 2.4.12 Plan de validacién, verifi- cacién y pruebas. * Objetivo de Control. La matadologia de ciclos de vida del desarrollo de sistemas de la organizacion deblera exigir que se establezca un plan de validacién, verificacién y prueba para cualquier proyecto de desarrollo y modificacién de sistemas de informa- cion, * Directiva de Auditoria. Deben revisarse las especificaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion de que debe establecerse un plan de validacién, verificacion y pruebas para cada proyecto de desarrollo y modifica~ cién de sistemas de informacion. 1. Determinar, para proyectos seleccio- nados de desarrollo y modificacién de sistemas, si se ha establecido un plan para probar el sistema y su logical. 2. Apreciar si este plan incluye criterios de medidas y restituciones adecuadas, criterios de reduccién de datos de prue- ba y de evoluacién tanto para la fase de desarrollo cuanto para la de pruebas del producto final, y que el mero cumpli- miento del mismo no dara lugar prue- bas insuficientes 0 inadecuadas. 3. Determinar, mediante entrevistas con las personas implicadas y mediante una revision de la documentacién relati- va a proyaclus seleccionados de desa- rrollo y modificacion de sistemas de infor- macion, si los pruebas exigidas fueron: a. llevadas a cabo por un numero suficiente de personas cualficadas independientes de! equipo de pro- yecto b. efectuadas con participacién adecuada de representantes de los departamentos usuarios afectados c. efectuadas en el entorno en el que el sisterna se usaré realmente. 1216 4. Determinar, mediante entrevistas on los individuos implicados. y median- to una revision de la documentacién de proyectos soleccionados de desarrollo y modificaclon de sistemas de informacién, si el plan de pruebas contemplaba: a. la disposicién necesaria de mate- tial y datos b. un adecuado entrenamiento de usuarios u operadores c. los contratos de programas de pruebas, ficheros y datos adecuados d. la recogida y anéilss de los datos pertinentos e. la escritura de los informes exigi- dos. 5. Deferminar, mediante una revision de la documentacién de pruebas de proyectos seleccionados de desarrollo y modificacion de sistemas de informa- ci6n. @. [a fuente, tipo y adecuacién de! Juego 0 generador de pruebas b. los datos de transacciones reales cc. el andllisis de los resultados de 1a prueba, 2.5 DESARROLLO E IMPLANTACION. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacién debiera establecer, para cada proyecto de desarrollo o modificacién de sistemas de informacién que los objetivos de pro- gramacién debieran ser establecidos para el proyecto y debieran asignarse tesponsabliidades para llevar a cabo la programacién, que debieran prepararse manuales del sistema, definirse los estén- dares de pruebas de programas y siste- ma, establecerse los ctiterios de valida- cién y aceptacién del sistema, y asegu- rarse la aceptacién del sistama por Ia direccion del departamento usuario afectado. 2.5.1 Objetivos de programa clén. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacién ‘exigir que se establezca una declaracion escrita de los objetivos de programacién llevar a cabo para cada proyecto de desarrollo y modificaci6n de sistemas de informaci6n. + Directiva de Auditoria, Deben revisarse las especificaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion respecto a la realizaci6n de una decla- raci6n escrita de los objetivos de progra- maci6n a ser efectuados para cada pro- yecto de desarrollo y modificacién de sistemas de informacién. 1. Revisar 1a documentacion de pro- yectos seleccionados de desarrollo y modificaci6n de sistemas de informacion y deferminar si incluye declaraciones escritas adecuadas de los objetivos de programacién a alcanzar en el proyecto y si tales declaraciones son conformes con las disposiciones pertinentes de la metodologia de ciclo de vida del desa- rrollo de sistemas de la organizaci6n. 2.5.2. Descripcién de la narrativa del programa. * Objetivo de Control. La metodologia del ciclo de vida del desarrollo de sistemas de Ia organizacién debiera exigir que se produjese durante el proyecto una declaracién escrita de los objetivos de programacién a alcan- zar durante el proyecto para cada pro- yecto de desarrollo y modificacién del Ciclo de vida del desarrollo de sistemas. * Directiva de Auditoria. Deben revisarse las especificaciones de la metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacién 1217 OBJETIVOS DE CONTROL, 1990. de que se establezca una declaracion escrita de los objetivos de programacion a alcanzar para cada proyecto de desarrollo y modificaci6n de sistemas de informacion. 1. Revisor la narrativa detallada pre- parada como parte de la documenta- ci6n de los programas y determinar la extension en que es conforme con la narrative original de definicion del siste- ma (en ocasiones puede usarse como parte de la documentacion final de programas pero normaimente habré de ser escrita de conformidad con el pro- grama tal y como esta realmente escri- to. y para refigjar la logica desarollada por el programador). 2. Revisar la documentacién de pro- yectos seleccionados de desarrollo y modificacién de sistemas de informacion y determinar si la narrativa légica deto- llada ha sido escrita de forma clara y concisa de forma que personas que no estén familiarizadas con e! programa fueran capaces de entender su funcién. 3. Deferminar, mediante una revision de la documentacién de proyectos seleccionadas de desarrollo y modi cacién de sistemas de informacion. Sila metodologia de ciclo de vida del desa- rrollo de sisiemas de la organizacién exige que se prepare un fiujograma a nivel de programa para cada proyecto y si la documentacién existente es con- forme con dicha especificaci6n. 4, Determinar, a partir de una revision de la documentacién de proyectos seleccionados de desarrollo y modifica- cién de sistemas de informacién, si las descripciones de ficheros y las maquetas de los informes son conformes con las determinaciones con la metodologia de ciclo de vida del desarrollo de sistemas de la organizacién. 5. Determinar, mediante una entrevista con el administrador de bases de datos de la organizacion y mediante una revision de la documentacién de pro- yectos seleccionados de desarrollo y modificacin de sistemas de informa- PARTE I - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO clon, silos elementos de datos emplea- , dos en los proyectos seleccionados. a. tienen designaciones descritas b. estén adecuadamente descritas ¢. no estén en conflicto con otras definiclones en el sistema de base de datos. 2.5.3 Paquetes de logical de aplicacién. * Objetivo de Control. la metodologia de ciclo de vida del desarrollo de sistemas de fa organizacion debiera exigir que se determine la dispo- nibiidad de paquetes de logical comer cial que pudieran satistacer las necesi- dades de un determinado proyecto de desarrollo 0 modificaci6n de sistemas de informaci6n. Los paquetes de logical ‘comercial debleran ser compatibles con las operaciones de proceso actuales del departamento de informética antes de asignar a miembros de la piantilla del departamento para efectuar cuaiquiera programacion relativa a estos proyectos. los procedimientos de adquisicién de productos logical debieran seguir las poltticas de adquisicion de la organize- cién y dichos productos debieran ser probados y revisados antes de pagar por ellos y ponerios en uso. * Directiva de Auditoria. Deben revisarse los determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizaci6n referentes a Ia seleccién y adquisicién de paquetes de logical de aplicacién. 1. Revisar los informes de los estudios de viabllidad econémica de proyectos seleccionadas de desarrollo 0 modifica- cin de sistemas de informacién y defer- minar sise contemplé adecuadamente la adquisicion de paquetes de logical. 2. Revisar, para proyectos selecciona- dos de desarrollo modificacion de siste- mas de informaci6n, los acuerdos selec- 12-18 cionados con Ia adquisicin de paque- tes de logical para deferminar si: @. sus disposiciones son conformes con las poliicas de adauisicién pert nentes en la organizacion y si fueron ‘aprobadas por escrito porla direccin de los departamentos usuarios afecta- dos y del departamento de informéti- ca b. la documentacién suministrada: con estos paquetes y los controles incorporados en los propios programas eran adecuados Cc. los propios paquetes fueron proba- dos y revisados antes de ser utilizados y pagades. 25.4 Contratacién de progra- mas de aplicacién a medida. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacin debiera estoblecer que la contratacion de programas de servicios de programa- cién a medida ha de estar justificada mediante una peticién escrita de un director de proyecto (los productos - finales de los servicios completos de programas a medida debieran ser pro- bados y revisados por el grupo de go- rantia de colidad de! departamento de informatica, antes de que se apruebe el pago de! trabajo y el producto final) * Directiva de Auditoria. Deben revisarse las determinaciones de Ja metodologia del ciclo de vida del de- sarrollo de sistemas de la organizacién que tratan con Ia solicitud y adquisici6n de servicios de programacién a medida y con las pruebas del producto final de tales servicios. 1. Revisar, para proyectos selecciona- dos de dasarrolio 0 modificacién de sis- temas de informacién, las solicitudes para contratacién de programacién a medida para determinar: c. Ia razonabilidad de las peticiones 'b. Ia aprobacién de dichas peticio- nes previa a la gestion de adquisicion de los servicios c. que el enunciado: de los servicios a ser prestados, las estipulaciones para asegurar que se aicanzan los tendimientos deseados, las determina clones en cuanto a contingencia para el. caso de que el contratista fale en ejecutar 0 prestar el servicio y otros précticas relatives a la adquisicion que se hallan seguido son conformes con las determinaciones pertinentes de la politica de adquisicin de la organizacion., 2. Determinar, mediante entrevistas y una revision de la documentacion relati- va a proyectos seleccion de desarrollo 0 modificacion de sistemas de informacién si el prestador de los servicios de pro- gramacién a medida recibi6 unas direc- trices adecuadas respecto a los estin- dares de documentacién de programas de la organizaci6n y las disposiciones de declaracién de objetivos de programa- cién del proyecto y las narratives de programas asociados. 3. Revisar la documentacién de serv clos de programacién a medida contra- fados para proyectos seleccién de desa- roll 0 modificacion de sistemas de informacion y determinar si la coaittico- cién, documentacién y controles de los programas desarrolios pro contratos fueron probados por el gruno de garan- tia de calidad del departamento de informética y que fueron aprobados de conformided con fas determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de fa organizacion y del contratista, 4. Revisar ja documentaci6n para servi- cios de programacién a medida contra- fados para proyectos seleccionados de desarrollo o modificacién de sistemas de informacion y determinar si los pagos efectuados en el marco del contrato es- tuvieron soportados por pruebas y apor- taciones pertinentes. 12.19 OBJETIVOS DE CONTROL, 1990. 2.5.5 Manual de operaciones y mantenimiento. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion deblera determinar que se preparenma- nuales de operacién y mantenimiento adecuados como parte de todo proyec- to de desarrollo o modificacién de siste- mas de informacion. * Directiva de Auditoria. Deben revisarse las disposiciones de la metodologia de ciclo de vida del desa- rrollo de sistemas de la organizacion que exigen que se preparen manuales de operaciones y mantenimiento adecua- dos como parte de todo proyecto de desarrollo 0 modificaci6n de sistemas de informacién. 1. Verificar que la metodologia de ciclo de vida del desarrollo de sistemas dela organizacién define la documenta- cién de operaciones o manual de explo- facién que hay que crear para cada proyecto de desarrollo o modificacién de sistemas de informacion. 2. Verificar, mediante entrevistas y revision de la documentacién relative a proyectos selecclonados de desarrollo 0 modificacién de sistemas informaticos, que el manual de explotacién corres- pondiente. a. es conforme con la metodologia de ciclo de vida del desarrollo de sisternas de la organizacion b. esaccesible a y comprensible por los operadores cc. es usado en las pruebas de logl- cal. 3. Verificar, para proyectos seleccio- nados el desarrollo 0 modificacién de sistemas de informaci6én que el corres- pondiente manual de explotacién espe- Cifica, para cada paso del trabajo. a. Ia funcién del programa PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO- b. las necesidades de equipo c. la explicacién de todos los mensa- jes de consola, con la respuesta pertl- nente del operador d. la creacién y formacién de dispo- ner de las salidas e. la adecuada identificacion de las etiquetas de los ficheros de salida f. los procedimientos adecuados de rearranque 0 notificacién en caso de condiciones de error 0 fallo g. os puntos de control para una adecuada operacién del programa entre pasadas del mismo. 2.5.6 Manual de usuario. * Objetive de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera determinar que se preparen ma- nuoles de usuarios adecuados como parte de todo proyecto de desarrollo o modificacin de sistemas de informa- ci6n. * Directiva de Auditoria. Deben revisarse las determinaciones de metodologia de ciclo de vida del deso- rrollo de sistemas de Ia organizacion que exigen que se preparen manuoles de usuarios adecuados como parte de cada proyecto de desarrollo 0 modifica- clon de sistemas de informacion. 1. Verificar que la metodologia de ciclo de vida de! desarrollo de sistemas de la organizacién define la documenta clén o manual de usuario a crear para cada proyecto de desaralio o modifica- cin de sistemas de informacion 2. Verificar, para proyectos seleccio- nados de desarrollo o modificaci6n do sistemas de informaci6én, que el manual de usuario incluye informacién adecua- da acerca de: a. laespecificacion y formato de los datos de entrada. b. la necesidad de totales de con- ‘trol. . ¢. Ia formacién de presentar los da- tos al departamento de informatica. d._ 1a responsabilidad para convertir los datos a forma legible por el orde- nador. e. laresponsabilidad para resolver los ‘errores u otras Inexactitudes. fla asignacién de prioridades de tratamiento. g. el horario y frecuencia de Ia dis- tribucion de salidas. h. Ia seguiidad, Ia retencién y ta disposici6n de las salidas. 1. la l6gica de programacion. J. el desarrollo de las formulas criticas. k. el registro de la aprobacién por el usuario. 1. el registro de solicitudes y aproba- ‘cin de cambio a los programas. m. los procedimientos de encendido de terminales, apertura de terminales. cierte de terminales y apagado de terminales. n. la descripcién de los mapas de pantalla de los terminales y de los comandos disponibles. 3. Verificar, mediante entrevistas y Tevision de proyectos seleccionados de desarrollo modificacion de sistemas de informacion, que los manuales de usua- ios se han distibuido de conformidad con las determinacianes pertinentes de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion y que dichos manuales se han usado para las pruebas de logical. 25.7 Plan de Formacién. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas dela organizaci6n deblera determinar que se prepare un plan adecuado para la formacién del personal de los deportamentos usuarios Gfectados y de los grupos de operacion y mantenimiento del departamento de Informatica, como parte de todo pro- yecto de desarrollo 0 modificacin del sistema de informacién. * Directiva de Auditoria. Deber revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion que exigen Ia elaboracién de los depar- famentos usuarios y de los grupos de ‘operaciones y mantenimiento del depor- tamento informatico. 1. Determinar, mediante una revision de proyectos selecclonados de desarro- llo © modificacion de sistemas informa- clénsi para cada uno de tales proyectos se ha preparade un pian escrito de formaci6n de Ia plantilia de los departa- mentos usuarios y de los grupos de ope- racién y mantenimiento del departa- mento de informatica, que verificar que el plan establece un plazo suficiente para completar las actividades de for- macion necesarias. 2.5.8 Estandares de prueba de programas. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de lo organizacion debiera determinar estindares para la prueba e implantacién del logical desa- rrollado como parte de cada proyecto de desarrollo 0 modificaci6n de sistemas de informacion * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion que establecen estandares para la prue- 42-21 QBJETIVOS DE CONTROL, 1990. ba e implantacién del logical desarrolla- do como parte de todo proyecto de desarrollo o modificacién de sistemas dea informaci6n. 1. Verlficar que la metodologia de ciclo de vida del desarrollo de sistemas de Informacion de la organizacion defi- ne esténdares adecuados para la prue- ba de implantacién del logical desarro- lado como parte de todo proyecto de desarrollo 0 modificaci6n de sistemas de informacion. 2. Determinar, mediante una revisién de la documentacién referente a pro- yectos seleccionados de desarrollo o modificacion de sistemas de informacién si los directivos y mandos del! departa- mento de informética, el grupo de ga- rantia de calidad y la direccién de los departamentos usuarios afectados esta- blecieron revisiones escritas de sus prue- bas y aprobaciones del trabajo de pro- gramacién llevado a cabo en tales proyectos. 3. Verificar que se programaron todas las funciones, se prob todo el codigo ejecutable y que dichos resultados eran ‘conformes con las especificaciones orig nales de programaci6n del proyecto. 2.5.9 Estndares de prueba de sistemas. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacién debiera establecer estandares para la prueba del sistema como tal, como parte de todo el proyecto de desarrollo © modificacién de sistemas de informa- clon. a * Directiva de Auditoria. Deben revisarse Ia determinacién de Ia metodologia de ciclo de vida del deso- trollo de sistemas de la organizacion que establecen estandares para la prueba del sistema como tal, como parte de todo proyecto de desarrollo o modifica- ci6n de sistemas de informacién. PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO 1. Verlficar que Ia metodologia de ciclo de vida de! desarrollo de sistemas de la organizacion define esténdares ‘cadecuados para Ia prueba de sistemos de informacion especificos y que dichos estindares son adecuados al tamano y complejidad del tratamiento de datos que se lleva a cabo por el departamen- to de informética. 2. Revisar los estindares para Ia prue- ba de los sistemas de informacién espe- ificos contenidos en la metodologia de Ciclo de vida del desarrollo de sistemas de la organizacién. 3. Determinar si los estindares deter- minan de forma adecuada I participa cién de representantes de los departa- mentos usuarios afectados y la de los miembros de la plantilla de programa cién y garantia de calidad de! departa- mento informatico, en la preparacién de datos de prueba para la revisi6n y apro- bacién de los resultados de las pruebas. 2.5.10 Documentacién de las pruebas de sistema. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistema de la organizaci6n debe establecer, como parte de todo proyecto de desarrollo 0 modificacion de sistemas de informacién, que los resultados de las pruebas de sistemas se incluyan en forma de reglstro escrito entre las actividades de! equipo el pro- yecto. * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida des desarrollo de sistema de la organizacién que establecen, como parte de todo proyecto de desarrollo © modificacién de sistemas de informacion, que los resultados de las pruebas de sistemas deben incluirse, como un registro escrito, entre las actividades del equipo de proyecto, 1. Determinar, mediante una revision de la documentacion referente a pro- yectos seleccionados de desarrollo o 12-22 modificacién de sistemas de informacion sh 9. elsistema fue probado de confor- midad con el plan de verificacion, validaci6n y prueba b. si todos los elementos principales del sistema fueron inciuldos en el pro- ceso de prueba. c. sel material de las pruebas se controlé adecuadamente durante el proceso de prueba d. {os resultados de! proceso fueron aprobads por las direcciones de los departamentos usuarios afectados, la del departamento de informatica, y el grupo de garantia de calidad de este departamento. e. el registro de este proceso de pruebas y aprobaci6n fue el adecua- do f. en los registros de actividades de! equipo de proyecto se incluyé un in- forme escrito sobre los resultados de las pruebas. 2. Determinar, mediante entrevistas con fa direcci6n de los departamentos usuc- Tios afectados y mediante revision de la documentacién de proyectos seleccio- nados de desarrollo o modificacion de sistemas de informacion, silos represen- tantes de los departamentos usuarios eran conscientes de la importancia del proceso de prueba, s! participaron en el mismo adecuadamente. y si se conside- raron a si mismos responsables, de la aprobacién de los resultados de! pro- ceso. - 3. Determinar, mediante la revisibn de las documentaci6én de pruebas de siste- ma para proyectos seleccionados de desarrollo o modificaci6n de sistemas de informacion, si los controles de acceso y autorizacién y las pistas de auditoric incluidas en el sistema eran adecuados. 4. Determinar si se han desarroliado procedimientos escritos adecuados por fa direccion bien de los departamentos escritos adecuados por|a direccion bien de los departamentos usuarios afecta- dos, bien del departamento de informé- fica, para mantener a adecuacion de tales controles y pistas de auditoria du- ante la explotacion del sistema. 2.5.11 Evaluacién de los resulta- dos de las pruebas. * Objetivo de Control. la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera establecer, como parte de todo proyecto de desarrollo de modificacion de sistemas de informacién, que los resultados de los pruebas de sistemas se evalien y aprueben por la direccién de los departamentos usuarios afectados y del Departamento de Informatica. * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion que establecen, como parte de todo proyecto de desarrollo 0 modificacién de sistemas de informacién, que los resultados de las pruebas de sistemas han de ser evaluadas y aprobadas por la direccién de los departamentos usua- rls afectados y la del departamento de informética. 1. Determinar, mediante una revision de la documentacién de pruebas relat- va a proyectos seleccionados de desa- rrollo 0 modificacién de sistemas de informaci6n, si antes de realizar las prue- bas de sistemas se desarrollaron sistemas previos determinados que se compara- ton con los resultados de las pruebas y que ambos coincidfan. (En los casos en que no hubiera coincidencia entre unos y otfos, el auditor debiera examinar tales diferencias y obtener una informacién ‘de dos individuos que participaron en el proceso de revision y aprobacién de las pruebas), 12-23 OBJETIVOS DE CONTROL, 1990. 2. Determinar, mediante una revision de la documentacién de pruebas co- mespondientes a proyectos selecciona- dos de desarrollo 0 modificacion de sistemas de informacién, si dicha comu- nicacién contiene Informacién como; . listado de datos de prueba b. Informes de las salidas del sistema ¢. opuntes pertinentes procedentes del diario del sistema operativo. 3. Deferminar, mediante una revision de la documentacién de pruebas co- respondiente a proyectos seleccionados de desarrollo o modificacién de sistemas de informacion, se efectuaron pruebas de respaido y recuperacion, de carga punta y de capacidad, de folio planifi ado, y del plan de contingencia. y de los resultados de tales pruebas fueron evaluados y aprobados por la direccién de los departamentos usuarios afectados y del departamento de informética, 2.5.12 Plan de Conversién. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas de la organizacion debiera establecer, como parte de todo proyecto de desarrollo o modificacion de sistemas de informacién. que se de- sarrolle un plan de conversion del siste- ma para pasario de desarrollo a explota- cién. * Directiva de Auditoria. Deben revisarse las determinacion de la metodologia de ciclo de vida del deso- rrollo de sistemas de la organizacién que exigen, con parte de todo proyecto de desarrollo o modificacién de sistemas de informacién que establezca un plan de conversion del sistema para pasarlo de desarrollo a explotacion. 1. Delerminar mediante una revision de la documentacién de proyectos seleccionados de desarrollo o modifi. cacién de sistemas de informacién si la direccion de los departamentos usuarios PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO afectados y del departamento de infor- matica desarroliaron un plan escrito ‘completo para la conversion del sistema de desarrollo a explotacién, que dicho pion era conforme con las determina- Clones de la metodologia de ciclo de Vida del desarrollo de sstemas de la organizacion, y que el plan contemplo- ba! una revision conjunta por la orga- nzacién previa a Ia Iniciacién del proceso de conversién, de la adecua- cin de la documentacién de progra- mas, de los manuales de explotacion y usuarios y de otros registros creados por el equipo de proyectos b. la asignacién de suficientes miem- bros de Ia plantilia al proceso de con~ version c. la imparticién a dichos individuos de la formacién adecuada en el uso de las determinaciones de ese proce- so de prueba. 2.5.13 Pruebas en Paralelo * Objetive de Control. Lo metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion deberia definirlas circunstancias bajo las cuales se ll6varé a cabo una prueba en paralelo del sistema actual y el nuevo y deberia especificar los ciiterios para terminar este proceso de prueba. * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de Ia organizacion que definen las circunstancias bojo las cuales se llevard a cabo una prueba en paralelo del sisterna actual y el nuevo y que ospecifican los criterios para termi- nar este proceso de prueba. 1}. Determinar, mediante una revision dela documentacién correspondiente o proyectos seleccionados de desarrollo o modificacién de sistemas de Informa- ‘ci6n, sila decision por la direccién de los departamentos usuarios afectados y de! 12-24 departamento de Informatica de exigir que el sistema se sometiese a una pruc- ba en paralelo durante el proceso de conversion. a. estaba soportada por un anélisis coste-beneficio adecuado b. _brindaba una bose para resolver cualesquiera problemas de tratamien- fo encontrados durante la prueba c. _ establecia critetios adecuados para terminar el proceso de prueba (el auditor debiera veriicar que la decision real de terminar la prueba en paralelo en el caso de cada uno de los proyectos seleccionados era con- forme con|os ctiterios establecidos por la direcci6n). 25.14 Prueba de aceptacién final. * Objetivo de Control. La metodologia de ciclo de vida del desarrollo de sistemas debiera estable- cer, como parte de las pruebas de o- ceptaci6n final o de garantia de call- dad de un sistema de informacion nue- vo © modificarlo, que se evaluen los resultados de las pruebas por direcci6n de los departamentos usuarios afectados y del departamento de informética. * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion que exigen. como parte de los pruebas de aceptaci6n final 0 de garantia de calidad de un sistema de informacion nuevo © modificado, que Ia direccién de los departamentos usuarios afectados y la del departamento informética efoc- tuen una evaluacién de los resultados de las pruebos. 1. Verificar que la metodologia de ciclo de vida del desarrollo de sistemas de la organizaci6n define esténdares adecuados para las pruebas de acepta- clén final de sistemas de informacion nuevo 0 modificados. 2, Determinar, mediante una revision de la documentacién de proyectos selacclonados de desarrollo 0 modifi cacion de sistemas de Informacion, si la diteccién de los departamentos usuarios Gafectados, la del departamento de informatica. y los miembros del grupo de gorantia de calidad del departamento, Participaron el una evaiuacion del fun- Clonamiento del nuevo sistema. 3. Determinar si las posibies ineficien- ‘Clas en dicho funcionamiento s remedia- ron antes de deciarar operativo al siste- ma. 2.6 EXPLOTACION Y MANTENIMIENTO. la metodologia de ciclo de vide del desarrollo de sistemas de Ia organizecion debiera establecer, para cada proyecto de desarrollo o modificacion de sistemas de informacién, que se establezcan los procedimientos de explotacion ymante- himiento que aseguren que los datos se tratan de forma congruente y exacta y que el contenido de sistemas solo sera modificado mediante autorizacion ade- cuada, 2.6.1 Procedimientos de control de explotaci6n. * Objetivo de Control, La metodologia de ciclo de vida del desarrollo de sistemas de a organizocion debiera asegurar que se han instalado procedimientos adecuades para contro- lar las actividades de tratamientos de datos de un sistema de informacion nuevo 0 modificado. * Directiva de Auditoria. Deben revisarse las determinaciones de la metodologia de ciclo de vida del desarrollo de sistemas de la organizacion que exigen Ia instalacion de procedi- mientos adecuades para el control de las actividades de tralamientos de datos 12:25 OBJETIVOS DE CONTROL, 1990. de un sistema de informacion nuevo O modificado. cacién de sistemas de informacion, silos procedimientos de control establecidos or la organizacion de los departamen- fos usuarios afectados y del departo- mento de informatica son adecuados para él tipo de ficheros que se mantiane ¥ para las transacciones que se proce san por el nuevo sistema. 2, Determinar que los procedimientos jncluyen controles de fa distribucton de las salidas del sistema de forma que solo representantes autorizados de los depor- fomentos usuarios ofectados reciben dichas salidas. 3. Deferminar que los procedimientos Tseguran que los erores detectados durante fa explotacion del sistema se identifican, controlan, corrigen y vuelven a tratar se adecuadamente. 4, Determinar que los procedimientos ‘seguran que las funciones clave de explotaci6n, incluidas la explotacion de programas de aplicacion, la seguridad de datos, la creacién y entrada de datos, y la gestion de bases de datos relacionados con el sistema se efectton por individuos distintos y que Ia direccion impone eso separacién de funciones. 2.6.2 Control de costes. * Objetivo de Control. El sistema de contabllidad de ia organ zacién debiera. de forma rutinaria, re- gistrar, analizar e informar sobre los Cos: fes asociados con la explotacién de un nuevo sistema de informaci6n. * Directiva de Auditoria. Deben revisarse los procedimientos em pleads por el sistema de contabllidad Ge la organizacién para registrar, anali- zar é informar, de forma rutinarla, sobre PARTE | - 2. CONTROLES DE DESARROLLO, ADQUISICION Y MANTENIMIENTO- los costes asociados con la explotacion ‘Ge un nuevo sistema de Informacion. 1, Revisar los procedimientos empiea- dos por el sistema de contabilidad dela Srganizacion para registrar, analiza, © informar, de forma tutinaria, sobre los Costes asoclados con Ia expiotacion de Gn nuevo sistema de Informacion. ‘aprobados por portamentos usuarios afectados ¥ del departamento de Informética. 2.6.3. Modificaciones al sistema. + Objetive de Control. La metodologia de ciclo de vida de Gesarrollo del sistema de Ie organizacion Gebiera establecer procedimientos para hacer un saguimiento y control de los ‘cambios de todos los sistemas de Infor macién en expiotacion * Directiva de Auditoria. Deben revisarse las determinaciones de Ja metodologia de ciclo de vida desa- rrollo de sistemas de Ja organizacién que Getablecen las bases para el seguimiento y control de ‘cambios de todos los siste- mas de informacién en explotacion. 1, Determinar, mediante una revision de Ia documentacién de sistemas de infor maci6n en expiotacion seleccionados si las propuastas de cambios o las modi Gociones a tales sistemas se registran ¥ procesan de modo oportuno. 2. Determinarsilos cambios 0 mocifica Ciones propuestos para tales sistemas son @probados por la direcci6n del departo- mento usuarios antes de que comience a trabajarse en ellos. 3, Determinar que 10s registros de los cambios introducidos. incluso las revisio- hes de flujagramas o tablas de decision y la evaluacion y aprobacién de los Yesultados de las pruebas se incorporan la documentacion ccumulade para 12-26 este sistema por el departamento de informética. 2.6.4 Re-evaluacién de las espe- cificaciones de usuarlo. * Objetivo de Control. La metodologia de ciclo de vide de Gesarrolio del sistema de fa organizacion Gebiera establecer la revision periédica de las especificaciones de usuarlo para Sistemas de Informacion espectficos a fin Ge determinar si y como han cambiado dichas especificaciones. * Directiva de Auditoria. Deben examinarse las determinaciones de la metodologia de ciclo de vida de Gesarrollo del sistema de la organizacion que exigen la revision periddica de fos especificaciones de usuario para siste” fos de informacion espectficos a fin de Geterminar si y como pueden haber cambiado tales especificaciones. 1, Determinar, mediante una revision de Jas peticiones pendientes de modifica” Giones a sistemas de Informacién en et departamento de Informatica, Ia exten sion de las necesidades de fos usuarios no satisfechos. 2. Determinar, mediante entrevistas © Gistibucion de Un cuestionario, la natura eza de los cambios buscados en tales sistemas, por la direccion de los departa~ mentos usuarios. 3, Verificar que los sistemas en cuestion ‘biindan a [os usuarios informacion en formato adecuado y de forma preciso. ‘oportuna, completa y fiable. 2.7 REVISION POST-IMPLANTACION. La metodologia de ciclo de vido 3e desarrollo del sistema de la organizaci6n Gebiera estoblecer una revisin comple fo uno vez implantado el sistema de informacién. de cada proyecto de desa- trollo 0 modificacion, para asegurar que fel esfuorzo tuvo como resultado un sisto- ma que satistace las necesidades de los usuarios y los objetivos declarados, que ‘esté produciendo los beneficins que se esperaba, y que satistace las especit- caciones de la metodologia. 2.7.1 Plan de revisién post-im- plantaclin. * Objetivo de Control. La metodologia de ciclo de vida de desarrollo del sistema de la organizacién debiera establecer como parte integral de las actividades de! equipo de pro- yecto, el desarrollo de un plan para ‘efectuar una revision post-implantacion de lodo sistema de informacién nueva o modificada. * Directiva de Auditoria. Deben examinarse los determinaciones de la metodologia de ciclo de vida de desarrollo del sistema de la organizaci6n para el desarrollo, como parte integral de las actividades del equipo de pro- yecto, de un plan para ejecutar una revision post-implantacién de todo siste- ma de informacién nuevo o modificado. Determinar, mediante un examen de la documentaci6n de sistema de informa ci6n en expiotaci6n seleccionados, si el equipo de proyecto de desarrollo o modificacion establecié un plan de revision post-implantaci6n, que incluya + a, una fecha prevista para la revision que prevea un tiempo suficiente co- mo para que el sistema esté plena- mente operativo b. Ia acumulacién de datos para efectuar la revision cc. quién ha de efectuar la revisibn d. — objetivos bien definidos de la revision e. el dmbito y naturaleza de la revi- sién y los recursos necesarios para ella 12-27 OBJETIVOS DE CONTROL, 1990. f. la preparaci6n y publicacién de un informe con los resultados de Ia revi- sién. 2.7.2. Evaluacién de resultados. * Objetivo de Control. La metodologia de ciclo de vida de desarrollo de! sistema de la organizaci6n debiera exigit que una revision post- implantacién de un sistema de Informa- cién operativo evalie si se han alcanza- do los objetivos del sistema. * Directiva de Auditoria. Deben examinarse las especificaciones de la metodologia de ciclo de vida de desarrollo del sistema de la organizacion que establecen que debe efectuarse una revision postimplantacién de los sistemas do informacion operatives para evaluar si se han alcanzado los objetivos de dicho sistema. 1. Deferminar, mediante examen de la documentacién de sistemas de informa- cién en explotacién, si la revision post- implantaci6n comparé el sistema actual con las especificaciones pertinentes. ‘especialmente en términos de : a." procedimientos de respaido y recuperacion b. mantenimiento y segregacién de funciones cc. pistas de Auditoria d. controles sobre las interfaces con otras aplicaciones y sistemas e. medidas de seguridad f. documentacién distribuida a los usuarios,

You might also like