traducciÓn de artÍculo de revista de auditorÍa
TRANSCRIPT
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.