La NIA-ES 315.28 exige que el auditor comprenda los controles relevantes para la auditoría, incluyendo las actividades de control general de TI. Cuando el sistema contable reside en la nube, una parte sustancial de estos controles se transfiere al proveedor de servicios.
Tabla de contenidos
- Por qué la contabilidad en la nube cambia la auditoría
- Evaluación del riesgo: controles que ya no controla el cliente
- Procedimientos de auditoría específicos para sistemas en la nube
- Ejemplo práctico: auditoría de Servicios Logísticos Cantábricos S.L.
- Lista de verificación práctica
- Errores frecuentes
- Contenido relacionado
Por qué la contabilidad en la nube cambia la auditoría
La NIA-ES 315.28 exige que el auditor comprenda los controles relevantes para la auditoría, incluyendo las actividades de control general de TI. Cuando el sistema contable reside en la nube, una parte sustancial de estos controles se transfiere al proveedor de servicios.
Controles tradicionales vs. controles en la nube
En un sistema tradicional, el cliente mantiene control directo sobre:
En la nube, estos controles pasan al proveedor de servicios. El cliente retiene control únicamente sobre:
Implicaciones para la evaluación del riesgo
La NIA-ES 315.15 requiere que el auditor identifique riesgos de incorrección material a nivel de aseveración. En entornos de nube, surgen riesgos específicos:
Riesgo de continuidad: Si el proveedor experimenta interrupciones, el procesamiento contable se detiene. Esto afecta a las aseveraciones de integridad y corte.
Riesgo de acceso no autorizado: Los controles de acceso dependen de la configuración del proveedor y la gestión de credenciales del cliente. Afecta a todas las aseveraciones.
Riesgo de pérdida de datos: Las copias de seguridad y la recuperación dependen del proveedor. Impacta la aseveración de existencia.
Riesgo de procesamiento incorrecto: Las actualizaciones automáticas pueden introducir errores de cálculo. Afecta a la aseveración de exactitud.
- Acceso físico a servidores
- Configuración de usuarios y permisos
- Copias de seguridad y recuperación
- Actualizaciones del sistema
- Segregación de entornos (producción vs. pruebas)
- Asignación de roles de usuario dentro de la aplicación
- Configuración de aprobaciones de transacciones
- Parámetros de negocio (cuentas contables, centros de coste)
- con otras aplicaciones
Evaluación del riesgo: controles que ya no controla el cliente
Análisis de la arquitectura de control
Bajo NIA-ES 315.21, el auditor debe obtener conocimiento de los controles relevantes. En sistemas de nube, esto requiere mapear qué controles ejecuta cada parte:
Controles del proveedor de servicios:
Controles del cliente:
Evaluación de controles del proveedor
La NIA-ES 402.9 establece que 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 del cliente.
Para plataformas de contabilidad en la nube, esto incluye:
Revisar los informes SOC 2 Type II del proveedor (cuando estén disponibles). Estos informes cubren controles de seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad.
Evaluar las certificaciones del proveedor: ISO 27001 para gestión de seguridad de la información, SOC 1 Type II para controles de información financiera.
Comprender los acuerdos de nivel de servicio (SLA): Tiempo de actividad garantizado, tiempo de respuesta ante incidentes, procedimientos de recuperación ante desastres.
Evaluación de controles del cliente
Los controles que permanecen bajo responsabilidad del cliente requieren evaluación directa bajo NIA-ES 315.10:
Gestión de acceso: Revisar la matriz de usuarios y permisos, verificar que los accesos se otorgan según el principio de menor privilegio.
Configuración de controles automáticos: Examinar límites de aprobación, reglas de validación, segregación de funciones dentro de la aplicación.
Controles de interfaz: Cuando el sistema en la nube se integra con otros sistemas, evaluar la completitud y exactitud de las transferencias de datos.
- Seguridad física de centros de datos
- Respaldo y recuperación de datos
- Actualizaciones de seguridad
- Monitoreo de rendimiento del sistema
- Controles de acceso a la infraestructura
- Gestión de usuarios de la aplicación
- Configuración de flujos de aprobación
- Interfaz con otros sistemas
- Revisión de informes de excepción
- Controles de cierre contable
Procedimientos de auditoría específicos para sistemas en la nube
Pruebas de controles generales de TI
La NIA-ES 330.8 requiere que cuando el auditor planee confiar en controles, debe realizar pruebas de controles para obtener evidencia de que los controles operan eficazmente.
Para controles del proveedor:
Para controles del cliente:
Procedimientos sustantivos adaptados
Los sistemas en la nube modifican la naturaleza de los procedimientos sustantivos bajo NIA-ES 330.18:
Selección de muestras: Los datos están disponibles de forma inmediata, permitiendo análisis de poblaciones completas o muestras más grandes sin costo adicional.
Análisis de datos: Las herramientas de consulta nativa del sistema permiten análisis que antes requerían extracción de datos. Sin embargo, debe verificarse que las consultas capturen todas las transacciones relevantes.
Confirmaciones: Cuando la información de terceros se almacena en la nube, las confirmaciones pueden automatizarse parcialmente, pero debe mantenerse el control sobre el proceso de confirmación.
Consideraciones sobre la evidencia de auditoría
La NIA-ES 500.7 establece que la evidencia de auditoría es más confiable cuando se obtiene de fuentes independientes. En entornos de nube:
Evidencia directa del sistema: Capturas de pantalla, informes exportados directamente del sistema, logs de auditoría cuando estén disponibles.
Evidencia del proveedor: Informes SOC, certificaciones, notificaciones de incidentes, estadísticas de disponibilidad.
Evidencia del cliente: Configuraciones guardadas, revisiones de excepción documentadas, aprobaciones registradas en el sistema.
- Obtener y revisar informes SOC 1 Type II o SOC 2 Type II
- Verificar que el período cubierto por el informe coincida con el período de auditoría
- Evaluar las excepciones identificadas por el auditor de servicios
- Para períodos no cubiertos por informes, realizar procedimientos complementarios
- Inspeccionar la configuración de usuarios y roles en fechas específicas
- Observar el funcionamiento de controles automáticos (límites de aprobación, validaciones)
- Re-ejecutar controles de interfaz en muestras de transacciones
- Evaluar la supervisión de excepciones y alertas del sistema
Ejemplo práctico: auditoría de Servicios Logísticos Cantábricos S.L.
Perfil del cliente: Servicios Logísticos Cantábricos S.L., con sede en Santander, gestiona la distribución de productos farmacéuticos para el norte de España. Facturación anual: 8,7 millones de euros. Empleados: 45. Migró a NetSuite en enero de 2024.
Paso 1: Evaluación inicial del entorno tecnológico
Obtuvimos el inventario de sistemas de la entidad:
Nota de documentación: Registrar en PT-TI-01 el mapeo completo de sistemas y sus integraciones.
Paso 2: Identificación de controles relevantes
Controles de NetSuite/Oracle:
Controles de Servicios Logísticos Cantábricos:
Nota de documentación: Crear matriz de controles en PT-TI-02 identificando responsable (cliente vs. proveedor) y clasificación (general TI vs. aplicación).
Paso 3: Obtención de evidencia sobre controles del proveedor
Solicitamos a la entidad el informe SOC 2 Type II de NetSuite más reciente (período: 1 abril 2023 - 31 marzo 2024). El informe cubría:
Nota de documentación: Archivo completo del informe SOC 2 en PT-TI-03. Documentar evaluación de excepciones en PT-TI-04.
Paso 4: Pruebas de controles del cliente
Gestión de usuarios (muestra de 15 usuarios activos a 31/12/2024):
Controles de aprobación (muestra de 25 facturas >5.000€ en diciembre):
Nota de documentación: Registrar deficiencias identificadas en PT-TI-05 con evaluación de impacto en la estrategia de auditoría.
Paso 5: Ajuste de procedimientos sustantivos
Dada la deficiencia en controles de acceso, incrementamos el alcance de procedimientos sustantivos:
Nota de documentación: Modificaciones a la estrategia documentadas en PT-PL-01 con justificación basada en deficiencias identificadas.
Conclusión: La evaluación identificó deficiencias en la gestión de usuarios y controles de aprobación que requirieron ajustes en el alcance de procedimientos sustantivos. Los controles del proveedor (NetSuite) operaron eficazmente según el informe SOC 2.
- Sistema financiero: NetSuite (SuiteCloud)
- Gestión de almacén: WMS integrado con NetSuite via API
- Facturación: Módulo nativo de NetSuite
- Nóminas: Sistema local (no conectado)
- Centro de datos certificado ISO 27001
- Copias de seguridad automáticas cada 8 horas
- Actualizaciones de seguridad gestionadas por Oracle
- Monitoreo 24/7 de rendimiento
- Tres niveles de usuario: Visualización, Entrada de datos, Administrador
- Aprobación requerida para facturas >5.000€
- Conciliación bancaria semiautomática con revisión manual
- Cierre contable mensual con check-list de validación
- Seguridad: Sin excepciones identificadas
- Disponibilidad: 99,95% de tiempo activo (dentro de SLA del 99,9%)
- Integridad del procesamiento: Dos excepciones menores corregidas durante el período
- 12 usuarios con acceso apropiado según funciones
- 2 usuarios de empleados que dejaron la empresa en octubre (deficiencia identificada)
- 1 usuario administrador sin segregación adecuada de funciones
- 23 facturas con aprobación documentada en sistema
- 2 facturas sin aprobación (5.400€ y 6.750€) - deficiencia de control
- Análisis de todas las transacciones >1.000€ en lugar de muestra estadística
- Confirmación de saldos con 15 clientes principales (vs. 10 planificados originalmente)
- Revisión detallada de asientos de diario manuales en los últimos 3 meses
Lista de verificación práctica
- Obtener inventario completo de sistemas en la nube utilizados para el procesamiento financiero, incluyendo integraciones entre sistemas y flujo de datos.
- 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 limitaciones.
- Mapear la división de controles entre cliente y proveedor según NIA-ES 315.21, identificando específicamente qué controles generales de TI no están bajo control del cliente.
- Revisar configuración de usuarios y permisos a fecha de balance, comparando con estructura organizacional y principios de segregación de funciones.
- Evaluar controles automáticos del sistema (validaciones, límites, flujos de aprobación) mediante inspección de configuración y pruebas con transacciones de muestra.
- Documentar procedimientos de contingencia del cliente ante interrupciones del servicio, incluyendo SLA acordados y experiencia histórica de interrupciones durante el período auditado.
Errores frecuentes
- Asumir que los informes SOC cubren todos los controles relevantes. Los informes SOC se enfocan en controles de la plataforma, no en la configuración específica del cliente ni en controles de proceso de negocio.
- No evaluar la competencia del proveedor de servicios. Datos internacionales del IAASB indican que el 31% de las deficiencias en auditorías con organizaciones de servicios derivan de evaluación insuficiente de la organización de servicios.
- Confiar en controles del cliente sin evaluar su dependencia de controles del proveedor. Un control de conciliación del cliente es ineficaz si los datos subyacentes no son íntegros debido a fallas en controles del proveedor.
- No verificar que el período del informe SOC coincida con el período de auditoría. Si el informe SOC 2 cubre hasta marzo y el cierre es diciembre, quedan nueve meses sin cobertura; la NIA-ES 402.12 exige procedimientos complementarios para ese intervalo
Contenido relacionado
- Riesgos de auditoría en computación en la nube - Conceptos centrales 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.
- Hallazgos frecuentes del AFM sobre fraude (NIA-ES 240) - Cómo los reguladores evalúan la documentación de fraude y qué deficiencias encuentran con mayor frecuencia.
- Riesgo de auditoría - Definición del riesgo de auditoría y sus componentes bajo NIA-ES 315, incluyendo el riesgo inherente y de control en entornos tecnológicos.