Systems Development and Project Management Audit/Assurance ... · TI, Procesos de auditoría y...

13
Systems Development and Project Management Audit/Assurance Program Héctor Agustín Charry Osorio 1701413071 Auditoría Informática Universidad de Caldas Manizales 2017

Transcript of Systems Development and Project Management Audit/Assurance ... · TI, Procesos de auditoría y...

Systems Development and Project Management

Audit/Assurance Program

Héctor Agustín Charry Osorio

1701413071

Auditoría Informática

Universidad de Caldas

Manizales 2017

Introducción:

ISACA ha desarrollado IT Assurance FrameworkTM (ITAFTM) como un modelo integral y de

buenas prácticas. ITAF proporciona estándares que están diseñados para ser obligatorios y

son la guía principal bajo los que opera la profesión de auditoría y aseguramiento de TI. Las

pautas proporcionan información y dirección para la práctica de auditoría y garantía de TI.

Las herramientas y técnicas proporcionan metodologías, herramientas y plantillas para

proporcionar dirección en la aplicación de los procesos de auditoría y aseguramiento de TI.

El programa “audit/assurance” o programa de auditoría / aseguramiento se desarrolló para

ayudar al profesional de auditoría y aseguramiento a diseñar y ejecutar una revisión sobre

las diversas fases del proyecto.

El programa de auditoría / aseguramiento es una herramienta y plantilla para ser usada

como hoja de ruta con el fin de completar un proceso de aseguramiento específico. El

Comité de Aseguramiento de ISACA ha encargado que se desarrollen programas de

auditoría / aseguramiento para uso de los profesionales de auditoría y aseguramiento de

TI. Este programa de auditoría / aseguramiento está destinado a ser utilizado por

profesionales de auditoría y aseguramiento de TI con el conocimiento requerido del tema

bajo revisión, como se describe en ITAF, sección 2200-Normas Generales. Los programas de

auditoría / aseguramiento son parte de ITAF, sección 4000-IT Assurance Tools and

Techniques.

Los programas de auditoría / aseguramiento se han desarrollado en alineación con los

Objetivos de control IT Governance Institute® (ITGITM) para información y tecnología

relacionada (COBIT®) -específicamente COBIT 4.1-utilizando generalmente aplicables y

aceptadas buenas prácticas, y reflejan ITAF, secciones 3400- Procesos de administración de

TI, Procesos de auditoría y aseguramiento de 3600-IT, y Administración de auditoría y

aseguramiento de 3800-IT.

Muchas organizaciones han adoptado varios marcos a nivel empresarial, incluido el Marco

de control interno del Comité de Organizaciones Patrocinadoras de la Comisión Treadway

(COSO). La importancia del marco de control se ha mejorado debido a los requisitos

normativos de la Comisión de Bolsa y Valores de los EE. UU. (SEC) según lo ordenado por la

Ley Sarbanes-Oxley de Estados Unidos de 2002 y legislación similar en otros países. Buscan

integrar los elementos del marco de control utilizados por el equipo general de auditoría /

aseguramiento en el marco de auditoría y aseguramiento de TI. Como COSO se usa

ampliamente, ha sido seleccionado para su inclusión en este programa de auditoría /

aseguramiento. El revisor puede eliminar o cambiar el nombre de estas columnas para

alinearlas con el marco de control de la empresa.

Programas de auditoría / aseguramiento:

El gobierno de TI, el riesgo y el control son críticos en el desempeño de cualquier proceso

de gestión de aseguramiento. La gobernanza del proceso bajo revisión se evaluará como

parte de las políticas y los controles de supervisión de la gestión. El riesgo juega un papel

importante en la evaluación de qué auditar y cómo la administración se acerca y maneja el

riesgo. Ambos problemas se evaluarán como pasos en el programa de auditoría /

aseguramiento. Los controles son el principal punto de evaluación en el proceso. El

programa de auditoría / aseguramiento identificará los objetivos de control y los pasos para

determinar el diseño y la efectividad del control.

El programa “audit/assurance” o programa de auditoría / aseguramiento se desarrolló para

ayudar al profesional de auditoría y aseguramiento a diseñar y ejecutar una revisión sobre

las diversas fases del proyecto.

El programa de auditoría / aseguramiento se segmenta según la fase. El profesional de

auditoría y aseguramiento debe personalizar y seleccionar esas fases dentro del alcance de

la revisión de auditoría / aseguramiento específica. Además, la evaluación de los controles

internos específicos basados en la aplicación a menudo está dentro del alcance y se aborda

en la sección Controles internos de este programa. Se alienta al profesional de auditoría y

aseguramiento a utilizar secciones de otros programas de auditoría / aseguramiento que

abordan aplicaciones específicas, operaciones de TI y otros temas relacionados con COBIT

que se ven afectados por el proyecto.

Pasos:

La primera columna del programa describe los pasos a realizar. El esquema de numeración

utilizado proporciona una numeración de papel incorporada para facilitar la referencia

cruzada al trabajo específico para esa sección. El documento físico fue diseñado en

Microsoft® Word. Se alienta al profesional de auditoría y aseguramiento de TI a realizar

modificaciones a este documento para reflejar el entorno específico bajo revisión.

Los pasos 1 y 2 son parte de la recopilación de hechos y la preparación previa al trabajo de

campo. Debido a que éste es esencial para una revisión exitosa y profesional, los pasos se

detallaran en el plan.

Comenzando en el paso 3, los pasos asociados con el programa de trabajo están

desglosados en items. Para simplificar el uso del programa, el programa de auditoría /

aseguramiento describe el objetivo de auditoría / aseguramiento: el motivo para realizar

los pasos en el área temática. Estos pasos pueden incluir la evaluación del diseño de control

al recorrer un proceso, entrevistar, observar o verificar de otra manera el proceso y los

controles que abordan ese proceso. En muchos casos, una vez que se ha verificado el diseño

del control, se deben realizar pruebas específicas para garantizar que se está siguiendo el

proceso asociado con el control.

El Programa de Auditoría / Aseguramiento de Desarrollo de Sistemas y Gestión de Proyectos

está destinado a ser utilizado durante las diversas fases del proyecto. En todas las fases, se

aborda la gestión de proyectos. Sin embargo, en sistemas específicos, los procesos de

desarrollo y los controles variarán en función de esa fase. Esas áreas de control no son

aplicables, están atenuadas. Esto le da al profesional la oportunidad de volver a agregarlos

al plan si corresponde.

Como usar el documento:

Referencia cruzada COBIT:

La referencia cruzada de COBIT proporciona al profesional de auditoría y aseguramiento la

capacidad de referirse al objetivo de control COBIT específico que respalda el paso de

auditoría / aseguramiento. El objetivo de control COBIT debe identificarse para cada paso

de auditoría / aseguramiento en la sección. Múltiples referencias cruzadas no son

infrecuentes. Los procesos en los niveles inferiores en el programa de trabajo son

demasiado granulares para ser referenciados de forma cruzada con COBIT. El programa de

auditoría / aseguramiento está organizado de una manera que facilita una evaluación a

través de una estructura paralela al proceso de desarrollo. COBIT proporciona objetivos de

control en profundidad y prácticas de control sugeridas en cada nivel. A medida que el

profesional revisa cada control, debe consultar COBIT 4.1 o la Guía de aseguramiento de TI.

Componentes COSO:

"COSO" (Committee of Sponsoring Organizations of the Treadway) es una Comisión

voluntaria constituida por representantes de cinco organizaciones del sector privado en

EEUU, para proporcionar liderazgo intelectual frente a tres temas interrelacionados: la

gestión del riesgo empresarial (ERM), el control interno, y la disuasión del fraude.

En 1992 la comisión publicó el primer informe “Internal Control - Integrated Framework”

denominado COSO I con el objeto de ayudar a las entidades a evaluar y mejorar sus sistemas

de control interno, facilitando un modelo en base al cual pudieran valorar sus sistemas de

control interno y generando una definición común de “control interno”.

COSO y marcos similares se han vuelto cada vez más populares entre los profesionales de

auditoría y aseguramiento. Esto vincula el trabajo de aseguramiento con el marco de control

de la empresa. Si bien la función de auditoría / aseguramiento de TI tiene a COBIT como

marco, los profesionales de auditoría y aseguramiento utilizan el marco establecido por la

empresa. Como COSO es el marco de control interno más prevalente, se ha incluido en este

documento y es un puente para alinear la auditoría / aseguramiento de TI con el resto de la

función de auditoría / aseguramiento. Muchas empresas de auditoría / aseguramiento

incluyen los componentes de control COSO dentro de su informe, y resumen las actividades

de aseguramiento al comité de auditoría de la junta directiva.

El marco de control interno original de COSO aborda las necesidades del profesional de

auditoría y aseguramiento de TI: ambiente de control, evaluación de riesgos, actividades de

control, información y comunicación, y monitoreo. Como tal, ISACA ha elegido utilizar el

modelo de cinco componentes para estos programas de auditoría / aseguramiento. A

medida que más empresas implementen el modelo de ERM, se pueden agregar las tres

columnas adicionales, si corresponde.

Referencia / Hipervínculo:

Las buenas prácticas requieren que el profesional de auditoría y aseguramiento cree un

documento de trabajo para cada elemento de línea, que describa el trabajo realizado, los

problemas identificados y las conclusiones. La referencia / hipervínculo se utilizará para

hacer una referencia cruzada del paso de auditoría / aseguramiento al documento de

trabajo que lo respalda.

Problema De Referencia Cruzada:

Esta columna se puede utilizar para marcar un hallazgo / problema que el profesional de

auditoría y aseguramiento de TI desea investigar o establecer como un hallazgo potencial.

Comentarios:

La columna de comentarios se puede usar para indicar la renuncia de un paso u otras

anotaciones. No debe usarse en lugar de un documento de trabajo que describa el trabajo

realizado.

Controla el análisis de madurez:

Una de las solicitudes consistentes de las partes interesadas que se han sometido a

revisiones de auditoría / aseguramiento de TI es el deseo de comprender cómo su

desempeño se compara con las buenas prácticas. Los profesionales de auditoría y

aseguramiento deben proporcionar una base objetiva para las conclusiones de la revisión.

El modelo de madurez para la gestión y el control de los procesos de TI se basa en un

método de evaluación de la organización, por lo que se puede calificar desde un nivel de

madurez de inexistente (0) a optimizado (5). Este enfoque se deriva del modelo de madurez

que el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon definió para

la madurez del desarrollo de software.

Nivel De Madurez Estado del entorno de control interno

Establecimiento de controles internos

0 Inexistente No hay reconocimiento de la necesidad de control interno. El control no es parte de la cultura o misión de la organización. Existe un alto riesgo de deficiencias e incidentes de control.

No hay intención de evaluar la necesidad del control interno. Los incidentes se tratan a medida que surgen.

1 Inicial / ad hoc Existe cierto reconocimiento de la necesidad del control interno. El enfoque de los requisitos de riesgo y control es ad hoc y desorganizado, sin comunicación ni monitoreo.

No se tiene conciencia de la necesidad de evaluar lo que se necesita en términos de controles de TI.

2 Repetible pero intuitivo Los controles están en su lugar pero no están documentados. Su funcionamiento depende del conocimiento y la motivación de las personas.

La evaluación de las necesidades de control ocurre solo cuando es necesario para los procesos de TI

3 Definido Los controles están en su lugar y adecuadamente documentados. La efectividad operativa se evalúa periódicamente y existe una cantidad promedio de problemas. Sin embargo, el proceso de evaluación no está documentado.

Los procesos críticos de TI se identifican en función de los factores de valor y riesgo. Se realiza un análisis detallado para identificar los requisitos de control y la causa raíz de las brechas y para desarrollar oportunidades de mejora.

4 Administrado y medible Existe un ambiente efectivo de control interno y gestión de

La criticidad del proceso de TI se define regularmente con

riesgos. Una evaluación formal y documentada de los controles ocurre con frecuencia. Muchos controles son automatizados y revisados periódicamente. Es probable que la gerencia detecte la mayoría de los problemas de control, pero no todos los problemas se identifican rutinariamente.

pleno respaldo y acuerdo de los propietarios del proceso comercial relevante. La evaluación de los requisitos de control se basa en la política y la madurez real de estos procesos, siguiendo un análisis minucioso y medido que involucra a los interesados clave.

5 Optimizado Un programa de control y riesgo brinda control continuo y efectivo y resolución de problemas de riesgo. El control interno y la gestión de riesgos se integran con las prácticas empresariales.

Los cambios comerciales consideran la importancia de los procesos de TI y cubren cualquier necesidad de reevaluar la capacidad de control del proceso.

Marcos de Control de ISACA:

COBIT es un marco de gobierno de TI y un conjunto de herramientas de apoyo que permite

a los gerentes cerrar la brecha entre los requisitos de control, los problemas técnicos y los

riesgos comerciales. COBIT permite un desarrollo claro de políticas y buenas prácticas para

el control de TI en todas las empresas.

La utilización de COBIT como marco de control en el que se basan las actividades de

auditoría / aseguramiento de TI alinea con las buenas prácticas desarrolladas por la

empresa.

Las áreas COBIT para esta evaluación incluyen:

PO10 Administrar proyectos.

AI1 Identificar soluciones automatizadas.

AI2 Adquirir y mantener el software de la aplicación.

AI3 Adquirir y mantener la infraestructura tecnológica.

AI4 Habilita la operación y el uso.

AI5 Adquiera recursos de TI.

AI7 Instalar y acreditar soluciones y cambios.

Systems Development and Project Management:

La metodología de desarrollo de sistemas (a veces denominada ciclo de vida de desarrollo

de sistemas) se compone de las fases implementadas en el desarrollo o adquisición de un

sistema de software. La experiencia ha demostrado que el desarrollo de un nuevo sistema

no puede ejecutarse en el vacío. La empresa debe participar como conductor, propietario y

gerente general del proyecto. El equipo de desarrollo de TI es miembro de este equipo de

proyecto general que es responsable de ejecutar el desarrollo técnico del plan de negocios.

Por lo tanto, la clave del éxito de cualquier iniciativa de TI es considerar el proyecto como

parte de un alcance mayor, que es la implementación de una solución empresarial. Para

mantener el proyecto bien encaminado, es necesario proporcionar gestión de proyectos,

un conjunto estructurado de actividades relacionadas con la entrega a la empresa de una

capacidad definida (que es necesaria pero no suficiente para lograr un resultado comercial

requerido) basada en un calendario acordado y presupuestado. Muchas entidades usan la

expresión "programa" para describir una iniciativa empresarial. La definición de programa,

una agrupación estructurada de proyectos interdependientes que incluye el alcance

completo de las actividades empresariales, de proceso, de personas, de tecnología y de

organización que se requieren (tanto necesarias como suficientes) para lograr un resultado

comercial claramente especificado, es un súper conjunto de un proyecto.

El desarrollo de sistemas ha utilizado tradicionalmente el enfoque de cascada, un ciclo de

desarrollo centrado en el procedimiento con el cierre formal al finalizar cada nivel. Los

procesos incluyen:

• Estudio de viabilidad

• Estudio de requisitos

• Definición de requisitos

• Diseño detallado

• Programación

• Prueba

• Instalación / acreditación

• Revisión posterior a la implementación

Con la llegada del prototipado, herramientas de desarrollo de aplicaciones de lenguaje de programación de cuarta generación (4GL) y otros enfoques, se necesitaron marcos más dinámicos. Estos incluyen: PMBOK, PRINCE2, Agile, RUP y Spiral.

Si bien cada marco utiliza diferentes convenciones de nomenclatura, los procesos clave son comunes a todos:

• Iniciación: preparación del concepto inicial, caso comercial, alcance, creación del equipo del proyecto y preparación y aprobación de solicitudes de presupuesto y gastos de capital.

• Planificación: preparación del plan detallado, definición de requisitos, ciclo de adquisición y adquisición de asistencia externa de consultoría.

• Ejecución: ejecución del plan del proyecto una vez que se completa la fase de planificación hasta la fase de puesta en marcha. Las subfases de la fase incluyen:

- Creación de procesos de negocio (automatizados y manuales), instrucciones y capacitación

- Estableciendo controles - Establecimiento de procesos de conversión y transición, rutinas de equilibrio

y verificación de la precisión e integridad del proceso. - Prueba:

Procesos de negocios Conversión Pruebas de estrés de los procesos Retrocesos

• Implementación • Reconciliación de la conversión • Go live-Actividades asociadas al comienzo del nuevo proceso • Proyecto cierre-cierre, contabilidad y costos finalizados • Post-implementación:

- Revisión del éxito del proyecto - Revisión financiera del caso de negocios vs. Resultados

La decisión de realizar revisiones en cada fase depende de los riesgos identificados y de la dependencia depositada en la aplicación. Las fases más importantes para los profesionales de auditoría / aseguramiento incluyen la planificación, la ejecución y la implementación posterior. La fase de iniciación puede requerir revisión si se cuestiona el caso comercial. Se recomienda que la fase de puesta en funcionamiento se revise después del hecho como parte de una revisión posterior a la implementación para garantizar que el proceso de auditoría / garantía no interfiera con las actividades de puesta en marcha.

Impacto y riesgo del negocio

Las aplicaciones desarrolladas o adquiridas son la columna vertebral de las operaciones de la empresa. Estos sistemas (tanto automáticos como manuales) proporcionan información a los sistemas de información financiera, son la fuente de análisis relacionada con las decisiones comerciales y realizan o controlan procesos críticos para el sustento de la empresa. La falla en la implementación del desarrollo de sistemas de buenas prácticas y la administración de proyectos puede resultar en:

• Selección de proveedor inapropiada

• Solución que no cumple con los requisitos comerciales y / o de usuario, que no funciona como se esperaba o que no puede integrarse con el plan de TI estratégico, la arquitectura de la información y la dirección de la tecnología.

• Malentendido de los objetivos y requisitos del proyecto

• Participación insuficiente de los interesados en la definición de los requisitos y la revisión de los entregables

• Solución incorrecta seleccionada o faltantes significativos descubiertos más adelante en el proyecto, lo que ocasiona retrasos costosos en la reelaboración y la implementación.

• Soluciones alternativas no identificadas

• Altos costos de soluciones fragmentadas

• Discrepancias contractuales y brechas entre las expectativas del negocio y las capacidades del proveedor

• La gerencia desconoce los riesgos en la adquisición de software

• Brechas entre controles y amenazas o riesgos reales

• Seguridad del sistema y confidencialidad comprometida

• Transacciones o transacciones no válidas procesadas incorrectamente

• Controles de compensación costosos

• Disminución de la disponibilidad del sistema e integridad cuestionable de la información

• Baja calidad del software, pruebas inadecuadas y un alto número de fallas

• Enfoque desorganizado e ineficaz para la gestión de proyectos, prioridades inadecuadas, funciones críticas demoradas, prioridades inadecuadas

• Presupuestos y recursos inadecuados

• Falta de respuesta a los problemas del proyecto con decisiones óptimas y aprobadas

• Responsabilidades y responsabilidades poco claras para asegurar el control de costos y el éxito del proyecto

Objetivos y alcance:

Objetivos: los objetivos del desarrollo de sistemas y la revisión de auditoría / aseguramiento de gestión de proyectos son:

• Proporcionar a la administración una evaluación independiente del progreso, la calidad y el logro de los objetivos del proyecto / programa en hitos definidos dentro del proyecto / programa.

• Proporcionar a la administración una evaluación de los controles internos de los procesos comerciales propuestos en un punto del ciclo de desarrollo donde las mejoras pueden implementarse fácilmente y adaptarse los procesos.

• Satisfacer los objetivos de auditoría / aseguramiento del proceso al revisar el proceso antes de su puesta en marcha, confiar en el proceso en el futuro basándose en el trabajo de aseguramiento realizado mientras la aplicación está en desarrollo e implementar técnicas integradas de auditoría asistida por computadora (CAAT) como parte de diseño de la aplicación

Alcance: la revisión se centrará en la fase (inicio / planificación / ejecución / cierre / post implementación) del proceso de desarrollo de sistemas para {insertar nombre de la aplicación}. Confiará en la metodología de desarrollo de sistemas para proporcionar una metodología de diseño, desarrollo y prueba y la metodología de gestión de proyectos para proporcionar una planificación, un presupuesto y un control de costes precisos y eficientes. Dentro de cada fase, la revisión abordará:

• Gobernabilidad • Gestión de proyectos • Presupuesto • Controles internos • Procesos de negocio • Proveedores de terceros y otras influencias externas