LO QUE TODO AUDITOR DE TI DEBE SABER ACERCA DE LOS

CONTROLES: EL CDLC Tommie W. Singleton, Ph.D.,

CISA, CITP, CMA, CPA, es un

profesor asociado de sistemas

de información (IS) de la

Universidad de Alabama en

Birmingham (EE.UU.), un

erudito IS Marshall y un director

del programa de contabilidad

forense. Antes de obtener su

doctorado en contabilidad en la

Universidad de Mississippi

(EE.UU.) en 1995, Singleton,

presidente de un pequeño

distribuidor de valor añadido de

IS contabilidad utilizando

microcomputadoras. Singleton

es también un erudito en

residencia de TI de auditoría y

contabilidad forense en Carr

Riggs Ingram, una gran empresa

de contabilidad pública regional

en el sureste de los EE.UU. En

1999, la Sociedad de Contadores

Públicos Autorizados de

Alabama otorgado Singleton

para el bienio 1998-1999

Usuario Innovador de

Tecnología Award. Singleton es

el defensor de ISACA académico

en la Universidad de Alabama

en Birmingham. Sus

publicaciones sobre el fraude,

IT/IS, IT de auditoría y gobierno

de TI han aparecido en

numerosas publicaciones,

incluido el Diario de ISACA.

Ha habido un claro incremento en la

atención a los controles en la

profesión de auditoría y la

comunidad empresarial. Se podría

argumentar que la nueva ola se

inició con los escándalos financieros

en el cambio de siglo, que culminó

en la promulgación de la Ley

Sarbanes-Oxley de 2002, o los

escándalos de la década de 1980,

que culminó en el Comité de

Organizaciones Patrocinadoras

(COSO) modelo de control interno y

la consiguiente Declaración de

Normas de Auditoría (SAS) No. 70,

"Examen de los controles internos

en una Auditoría de Estados

Financieros". Añadir a estos eventos

los requisitos de la Ley Sarbanes-

Oxley, sección 404, el "riesgo Suite"

(SAS N º 104-111, especialmente

109), y la evolución de SAS 70

auditorías a las auditorías de los

controles de TI para llegar a la

insistencia en los controles hoy. Los

controles son claramente una parte

fundamental de las auditorías de TI

de la presente, así como el futuro

previsible.

Pero los controles no son

simplemente la identificación de un

control que la gestión ha puesto en

marcha. Los controles, como los

sistemas, tienen un ciclo de vida. Al

igual que los sistemas de ciclo de

vida del desarrollo (SDLC), hay una

vida controla el desarrollo del ciclo

(CDLC). Los auditores de TI pueden

beneficiarse de la comprensión de

las fases del ciclo y cómo pueden

aplicarse a las auditorías de TI de

todo tipo.

En este artículo se presenta un

modelo de CDLC con el propósito de

describir el ciclo completo de

controles de desarrollo y la

presentación de la forma de aplicar

estas fases diferentes en las

auditorías de TI.

CONTROLES DE

DESARROLLO DEL

CICLO DE VIDA El ciclo de vida de los controles

consiste en una serie secuencial de

cuatro procesos:

1. Diseñar

2. Implementación

3. Efectividad operacional

4. Seguimiento

DISEÑAR

La fase de diseño implica el diseño

técnico de un control de potencial.

De alguna manera, la gestión,

intencionalmente o no, prevé el

diseño de todos los controles que se

aplican o se ejecutarán.

Los controles deben basarse en una

evaluación de riesgo y / o la gestión

de las políticas y procedimientos.

Pero, sobre todo, los controles

deben ser diseñados con la entrada

de un experto en los controles. Por

ejemplo, las siguientes deben ser

hechas:

• ¿Qué controles deben estar en su

lugar para detectar o prevenir

errores materiales a la información

financiera? Lo mismo debería ser

hecho con respecto a las

afirmaciones relevantes. (Nota:

Sustituir "errores materiales" con

cualquier otro efecto adverso.)

• ¿Cómo se garantizará una

información de gestión de entrada

de expertos y se aplica

sistemáticamente en el sistema de

control interno, comenzando con el

diseño?

• ¿Qué hacer en la gestión de una

manera formal que garantiza que los

cambios o adiciones de los procesos

de negocio incluyen el diseño eficaz

de los controles necesarios?

• ¿Ha desarrollado una gestión

adecuada evaluación de riesgos? Si

es así, los controles han sido

diseñados para mitigar cada uno de

estos riesgos (por encima de un

umbral)?

En ocasiones, la gestión, para una

variedad de razones, no tiene un

enfoque formal de diseño. Los

controles están diseñados por

casualidad o con el grado

profesionales de TI y directores de

unidades de negocios son capaces. El

auditor de TI debe hacer una

evaluación para determinar si una

persona debidamente cualificada o

de un grupo ofrece esta función en

la parte delantera de la CDLC. Podría

ser que un miembro del comité de

sistemas de dirección es un contador

o auditor (sin independencia

frustrante), que podría satisfacer

esta necesidad. Si nadie parece

aportar esta experiencia y no existe

una estructura formal para

asegurarse de que, la garantía de

que todos los controles necesarios

se han diseñado se deteriora y existe

una garantía de que la reducción de

la eficacia de diseño de los controles

es la adecuada.

El auditor de TI debe examinar el

diseño de los controles, de manera

individual (clave, los controles

pertinentes) y colectiva (por

ejemplo, son algunos de los

principales controles que faltan?),

Para evaluar la eficacia del diseño en

su capacidad para alcanzar el

objetivo (por ejemplo, mitigar el

riesgo , detectar una anomalía).

IMPLEMENTACIÓN

Hizo la gestión y / o empleados

realmente la aplicación del control

que fue diseñado en la primera fase?

En el cumplimiento de SAS N º 109,

en una auditoría financiera, en la

norma:

El auditor debe evaluar el diseño de

los controles de la entidad,

incluyendo las actividades de control

pertinentes, respecto de tales riesgos

y determinar si son adecuados y se

han aplicado.

Esta frase se repite varias veces en el

SAS No. 109. El auditor tiene la

responsabilidad de evaluar tanto el

diseño de los controles relacionados

y si se han ejecutado bien. Esa

responsabilidad es generalmente

llevada a cabo con la observación y /

o de inspección a través de un

recorrido.

El auditor de TI debe tomar alguna

determinación sobre la correcta

aplicación de todos los controles

diseñados.

EFECTIVIDAD OPERACIONAL

Mientras que los auditores han

estado examinando los controles, se

han preocupado de la eficacia

operativa real, es decir, la eficacia

del control en las operaciones diarias

y su capacidad para llevar a cabo su

objetivo (por ejemplo, prevenir o

detectar un error material).

En general, los controles son

manuales, automáticas o algún

híbrido de los dos. En la medida en

que un control es manual, o en parte

manual (es decir, híbridos), el

control está sujeto a la atrofia o la

negligencia humana. Un control

automatizado no debe estar sujeto a

estas enfermedades, pero no puede

funcionar como fue diseñado debido

a la aplicación defectuosa. Por lo

tanto, hay muchas cosas que pueden

salir mal entre el diseño y la eficacia

operacional. Los auditores de TI

tienen alguna obligación de

garantizar que los controles

funcionan de manera efectiva como

las evaluaciones independientes y

fueron concebidas o se ejecuten

correctamente.

Si bien un recorrido puede ofrecer

alguna garantía de la eficacia

operativa, pruebas de los controles

es el procedimiento final para hacer

esta evaluación. Obviamente, se

realizan pruebas de los controles en

una auditoría financiera sólo cuando

el auditor tiene la intención

a confiar en los controles. Siendo

realistas, por lo general hay al

menos unos cuantos controles en

una auditoría financiera en la que un

auditor se basará. En una auditoría

interna de TI, las pruebas de los

controles son fundamentales.

SEGUIMIENTO

La última fase es el seguimiento de

los controles. El cambio es inevitable

en los negocios. Los procesos de

negocio, las circunstancias, los

riesgos y las personas a cambiar (por

ejemplo, el volumen de negocios). La

probabilidad de que un control no se

requiere ningún cambio desde hace

varios años es mínima. Durante un

período de un año, el medio

ambiente va a cambiar bastante de

que algunos controles en el sistema

de control tendrá que ser cambiado,

borrado o agregado.

Entonces la pregunta es: ¿Qué

estructura formal debe estar en su

lugar para realizar esta función?

Ejemplos que deben ofrecer cierta

garantía de que existe vigilancia

incluyen:

• Un equipo multidisciplinario que

incluye al menos un experto en

control, donde el grupo se reúne

periódicamente para ofrecer

orientación y aportación a los

cambios en los sistemas y

tecnologías relacionadas con los

procesos de negocio y los controles

incorporados en la misma (por

ejemplo, uno de los principales

proyectos del comité directivo)

• Una revisión constante del actual

sistema de controles internos (que

son requeridos por la ley Sarbanes-

Oxley Sección 404 es un ejemplo)

• Un consultor o un grupo de

expertos que evaluará el sistema de

control interno con regularidad

• La auditoría continua / sistemas de

control (una solución superior,

cuando se aplican y gestionan de

manera eficaz)

De Inspección de las políticas y

procedimientos pueden

proporcionar alguna información

sobre si existe vigilancia. El auditor

de TI necesita para hacer las

investigaciones de la gestión y / o

empleados clave para determinar si

este pedazo de CDLC está en su

lugar.

Obviamente, una vez que esta

función determina la necesidad de

un cambio en el sistema de control

interno, el proceso de retorno a la

fase de diseño, y el ciclo se repite. La

vigilancia es la intención de

determinar cuando un control debe

ser modificado o eliminado, o

cuando un nuevo control es

necesario, y por lo tanto nos lleva al

diseño / rediseño del control.

CONCLUSIÓN Los controles son un elemento clave

de todos los tipos de auditorías de

TI. El modelo presentado aquí, CDLC,

constituye un enfoque que puede

ser aplicado en las auditorías de TI

para evaluar los controles. Los

auditores de TI pueden utilizar el

modelo de CDLC para mejorar su

capacidad para obtener garantías

sobre la fiabilidad del sistema de

control interno y los controles

individuales pertinentes.