Cómo la Contabilidad en la Nube Cambia Tus Procedimientos de Auditoría

Tabla de contenidos

1. El problema real: controles que desaparecen del mapa 2. Evaluación del riesgo: lo que dice la norma y lo que pasa en la práctica 3. Procedimientos de auditoría específicos para sistemas en la nube 4. Ejemplo práctico: auditoría de Servicios Logísticos Cantábricos S.L. 5. Lista de verificación práctica 6. Errores frecuentes 7. Contenido relacionado

El problema real: controles que desaparecen del mapa

He visto este patrón en más encargos de los que me gustaría admitir: el equipo de auditoría llega con un programa diseñado para un entorno on-premise y se lo encuentra todo en Sage 200cloud, Holded o A3innuva. Nadie actualizó la planificación. Los papeles de controles generales de TI se rellenan con lo que hay (que no es mucho) y el socio firma sin que nadie haya evaluado realmente si los controles del proveedor funcionan.

Lo que realmente ocurre es que la migración a la nube no elimina controles. Los redistribuye. Y esa redistribución crea una zona gris donde ni el cliente ni el auditor tienen visibilidad completa.

Qué pierde el cliente (y qué conserva)

En un sistema on-premise, el cliente mantiene control directo sobre el acceso físico a servidores, la configuración de usuarios, las copias de seguridad, las actualizaciones del sistema y la segregación de entornos. Cuando migra a la nube, todo eso pasa al proveedor. El cliente se queda con cuatro cosas: la asignación de roles de usuario dentro de la aplicación, la configuración de aprobaciones de transacciones, los parámetros de negocio (cuentas contables, centros de coste) y las integraciones con otras aplicaciones.

Parece poco, pero son exactamente los controles donde se concentra el riesgo de incorrección material. El problema es que esos controles del cliente dependen de que los controles del proveedor funcionen. Un control de conciliación bancaria del cliente no vale nada si los datos subyacentes están comprometidos por una brecha de seguridad en el proveedor.

Los riesgos que la nube introduce (o amplifica)

Bajo NIA-ES 315.15, el auditor debe identificar riesgos de incorrección material a nivel de aseveración. En entornos de nube, estos riesgos tienen características propias que no se dan en sistemas tradicionales.

Riesgo de continuidad. Si el proveedor sufre una interrupción, el procesamiento contable se detiene. He visto un caso en el que una empresa de distribución perdió acceso a su sistema de facturación durante once días por una migración fallida del proveedor. Once días sin poder emitir facturas ni registrar cobros. Cuando el sistema volvió, el equipo contable registró todo a mano y con prisa. Las aseveraciones de integridad y corte quedaron comprometidas.

Riesgo de acceso no autorizado. Los controles de acceso dependen de dos capas: la configuración del proveedor y la gestión de credenciales del cliente. Entre lo que dice el manual y lo que se hace hay un mundo. Por lo que he visto en los encargos que he llevado, la mayoría de pymes españolas comparten credenciales de usuario entre empleados porque "solo tenemos tres licencias." Esto destroza cualquier pista de auditoría sobre quién hizo qué.

Riesgo de pérdida de datos. Las copias de seguridad dependen enteramente del proveedor. El cliente suele asumir que "la nube no pierde datos." Esa suposición no es evidencia de auditoría.

Riesgo de procesamiento incorrecto. Las actualizaciones automáticas pueden introducir errores de cálculo sin que el cliente se entere. En mi caso, he encontrado una actualización de un sistema de contabilidad cloud que cambió la fórmula de cálculo del IVA intracomunitario durante dos semanas antes de que alguien lo detectase.

Evaluación del riesgo: lo que dice la norma y lo que pasa en la práctica

Mapa de la arquitectura de control

Bajo NIA-ES 315.21, el auditor debe obtener conocimiento de los controles relevantes. En la práctica, eso significa construir un mapa que responda a una pregunta sencilla: ¿quién controla qué?

Controles del proveedor de servicios: - Seguridad física de centros de datos - Respaldo y recuperación de datos - Actualizaciones de seguridad y parches - Monitoreo de rendimiento del sistema - Controles de acceso a la infraestructura

Controles del cliente: - Gestión de usuarios de la aplicación - Configuración de flujos de aprobación - Interfaces con otros sistemas - Revisión de informes de excepción

Casi ninguna firma mediana construye este mapa. Marcan la casilla de "conocimiento del entorno de TI" con un par de párrafos genéricos y siguen adelante. Eso no es evaluar controles; es documentar que no los evaluó.

Controles del proveedor: la dependencia del informe SOC

Según NIA-ES 402.9, cuando el cliente usa una organización de servicios, el auditor debe obtener conocimiento de la naturaleza de los servicios y su efecto en el control interno. Suena razonable. El problema está en la ejecución.

Informes SOC 2 Type II. Son la herramienta principal. Cubren controles de seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Pero tienen limitaciones que muchos auditores ignoran. Desde mi punto de vista, la más grave es que el período cubierto por el informe casi nunca coincide con el período de auditoría. Si su ejercicio cierra el 31 de diciembre y el SOC 2 cubre hasta el 31 de marzo del año anterior, tiene nueve meses sin cobertura. ¿Qué hace con esos nueve meses? La norma dice "procedimientos complementarios." La realidad es que muchos no hacen nada.

Certificaciones ISO 27001 y SOC 1 Type II. Son complementos, no sustitutos. Una certificación ISO 27001 le dice que el proveedor tiene un sistema de gestión de seguridad de la información. No le dice si ese sistema funciona para los controles específicos que afectan a la información financiera de su cliente.

Acuerdos de nivel de servicio (SLA). El tiempo de actividad garantizado, los tiempos de respuesta ante incidentes y los procedimientos de recuperación ante desastres son relevantes, pero son promesas contractuales, no evidencia de auditoría. Necesita comprobar el cumplimiento real.

Controles del cliente: donde se concentra el trabajo del auditor

Paradójicamente, los controles que permanecen bajo responsabilidad del cliente son los que más importan para la auditoría. NIA-ES 315.10 exige su evaluación directa.

Gestión de acceso. Revisar la matriz de usuarios y permisos. Verificar que los accesos se otorgan según el principio de menor privilegio. En la práctica, eso significa sentarse con el administrador del sistema y revisar usuario por usuario. No es un trabajo glamuroso, pero es donde se encuentran las deficiencias. He encontrado ex empleados con acceso activo en más de la mitad de los clientes con sistemas cloud que he auditado.

Controles automáticos de la aplicación. Límites de aprobación, reglas de validación, segregación de funciones dentro de la aplicación. Aquí es donde la nube tiene una ventaja real: estos controles suelen estar mejor documentados y ser más consistentes que en sistemas on-premise. Pero hay que probarlos, no asumir que funcionan porque el sistema es "moderno."

Controles de interfaz. Cuando el sistema en la nube se integra con otros sistemas (un WMS, una plataforma de e-commerce, un sistema de nóminas), cada punto de es un riesgo de completitud y exactitud. He visto integraciones que perdían transacciones de forma intermitente durante meses sin que nadie lo detectase.

Procedimientos de auditoría específicos para sistemas en la nube

Pruebas de controles generales de TI

Según NIA-ES 330.8, cuando el auditor planee confiar en controles, debe obtener evidencia de que operan con eficacia. Vaya por delante que en un entorno cloud, esto se complica porque una parte de los controles no son observables directamente.

Para controles del proveedor: - Obtener y revisar informes SOC 1 Type II o SOC 2 Type II - Verificar que el período cubierto coincida con el período de auditoría (o documentar cómo cubre la diferencia) - Evaluar las excepciones identificadas por el auditor de servicios. No basta con leer que hay excepciones; necesita evaluar si afectan a las aseveraciones relevantes para su auditoría - Para períodos no cubiertos, realizar procedimientos complementarios (indagaciones a la dirección, revisión de comunicaciones del proveedor sobre incidentes, análisis de logs disponibles)

Para controles del cliente: - Inspeccionar la configuración de usuarios y roles en fechas específicas (no solo a fecha de balance; también en fechas intermedias) - Observar el funcionamiento de controles automáticos con transacciones reales - Re-ejecutar controles de interfaz sobre muestras de transacciones - Evaluar la supervisión de excepciones y alertas del sistema

Procedimientos sustantivos adaptados

Un entorno cloud modifica la naturaleza de los procedimientos sustantivos bajo NIA-ES 330.18, aunque no siempre del modo que espera.

Selección de muestras. Los datos están disponibles de forma inmediata, lo que permite análisis de poblaciones completas. Esto es bueno. Lo que no es bueno es asumir que porque puede exportar "todos los datos," está viendo todos los datos. He comprobado que algunos sistemas cloud permiten exportaciones que excluyen transacciones eliminadas o modificadas. Si no verifica la completitud de su extracción, su análisis de población completa puede tener agujeros.

Análisis de datos. Las herramientas de consulta nativa del sistema permiten análisis que antes requerían extracción manual. Sin embargo, debe verificar que las consultas capturen todas las transacciones relevantes. Un filtro mal configurado puede excluir miles de registros sin generar ningún mensaje de error.

Confirmaciones. Cuando la información de terceros se almacena en la nube, las confirmaciones pueden automatizarse parcialmente. Pero debe mantener el control sobre el proceso de confirmación según NIA-ES 505. No es aceptable que el cliente le envíe "las confirmaciones que ya hizo el sistema." Usted necesita controlar a quién se envían, cuándo, y cómo se reciben las respuestas.

La evidencia de auditoría en entornos cloud

Según NIA-ES 500.7, la evidencia es más fiable cuando proviene de fuentes independientes. En entornos de nube, hay tres capas de evidencia y cada una tiene sus trampas.

Evidencia directa del sistema. Capturas de pantalla, informes exportados, logs de auditoría. Los logs son oro cuando existen, pero no todos los sistemas cloud ofrecen logs con el nivel de detalle que necesita. Y los que sí lo ofrecen, a veces los retienen solo durante un período limitado. Si no solicita los logs al inicio del encargo, pueden haber desaparecido cuando los necesite.

Evidencia del proveedor. Informes SOC, certificaciones, notificaciones de incidentes, estadísticas de disponibilidad. Son necesarios pero insuficientes por sí solos.

Evidencia del cliente. Configuraciones guardadas, revisiones de excepción documentadas, aprobaciones registradas en el sistema. Pida las configuraciones en formato exportable, no como capturas de pantalla que podrían ser de cualquier fecha.

Ejemplo práctico: auditoría de Servicios Logísticos Cantábricos S.L.

Perfil del cliente: Servicios Logísticos Cantábricos S.L., Santander. Distribución de productos farmacéuticos para el norte de España. Facturación: 8,7 millones de euros. 45 empleados. Migró a NetSuite en enero de 2024.

Lista de verificación práctica

1. Obtener inventario completo de sistemas en la nube que intervienen en el procesamiento financiero, incluyendo integraciones entre sistemas y flujo de datos. No se fíe de lo que le diga el cliente; pida acceso y verifique.

2. Solicitar informes SOC 1/SOC 2 Type II del período de auditoría. Si no están disponibles, evaluar certificaciones alternativas (ISO 27001, PCI DSS) y documentar las limitaciones con claridad.

3. Mapear la división de controles entre cliente y proveedor según NIA-ES 315.21. Identifique qué controles generales de TI no están bajo control del cliente y documente cómo los cubre.

4. Revisar configuración de usuarios y permisos a fecha de balance y en fechas intermedias. Comparar con la estructura organizacional real, no con el organigrama oficial.

5. Evaluar controles automáticos del sistema (validaciones, límites, flujos de aprobación) mediante inspección de configuración y pruebas con transacciones reales, no con datos de prueba.

6. Documentar procedimientos de contingencia del cliente ante interrupciones del servicio: SLA acordados, experiencia real de interrupciones durante el período, y qué hizo el cliente cuando ocurrieron.

Errores frecuentes

Contenido relacionado

- Evaluación del riesgo de TI - Conceptos para evaluar riesgos de tecnología de información en auditoría bajo NIA-ES 315.

- Calculadora de materialidad - Herramienta para calcular la materialidad considerando el impacto de sistemas automatizados en el riesgo de detección.

- Controles generales de TI - Guía para auditar controles generales de TI según NIA-ES 315 en diferentes arquitecturas tecnológicas.