Los controles generales de TI que importan al reporte

Una empresa cierra sus libros con sistemas: el ERP factura, el sistema de costos valora el inventario, el portal registra pedidos. Muchos controles clave son automáticos (un bloqueo, un cálculo, un cruce de tres vías) o manuales que dependen de un reporte que el sistema genera (el controller revisa un informe de costos). Ambos se apoyan en la tecnología: si el sistema se puede alterar sin control, el bloqueo ya no bloquea y el reporte ya no es confiable.

Los controles generales de TI (ITGC) son los que protegen a la tecnología en su conjunto: accesos, cambios a programas, operaciones y, cuando se desarrolla o adquiere software, su desarrollo. No protegen una cuenta directamente; protegen la fiabilidad de los controles que sí lo hacen. Por eso entran en el alcance solo para las aplicaciones de las que depende un control clave.

El resultado de los ITGC por aplicación tiene dos usos distintos. Uno es calificar la tecnología. El otro, más útil aquí, es cruzarlo con las dependencias de los controles clave: de qué aplicación depende cada uno y, si el control manual usa un reporte, si alguien probó que ese reporte es completo y exacto.

Una deficiencia en una aplicación de la que no depende ningún control clave importa menos para el reporte; la misma deficiencia en una aplicación que sostiene un control clave importa mucho. Las dos aplicaciones deficientes de esta empresa no pesan igual.

Los cambios a programas son el dominio donde más se nota la diferencia entre un control que funciona y uno que no. La lógica de un cálculo (aquí, el costo estándar) puede cambiar sin que nadie lo vea y alterar de forma sistemática el valor del inventario. Los criterios son concretos: aprobación del dueño antes del pase, prueba antes del pase y un pase que no haga el mismo desarrollador.

Para encontrar el cambio que incumple se usa el registro completo, no una muestra: la población es pequeña y es la que alimenta las conclusiones.

Un control general deficiente no equivale a un error en los estados financieros. Dice que el control que depende de él ya no se puede tomar como confiable por sí solo, y deja dos caminos. Uno es buscar otros controles que compensen y operen con precisión suficiente. El otro es probar directamente lo que la deficiencia deja sin garantía: aquí, que el reporte de costos que usa el controller es completo y exacto, o que los costos estándar cambiados son correctos.

Lo que no se hace es dar por bueno el control manual solo porque su firma esté en el papel, ni declarar un error que nadie ha medido.