Riesgos de auditoría en entornos de computación en la nube

Lo esencial

> - Los datos alojados en servidores remotos requieren procedimientos diferentes a los sistemas locales. El auditor obtiene acceso directo o se apoya en pruebas del proveedor. > - El control sobre la nube descansa parcialmente en el proveedor. La NIA-ES 402 exige evaluar sus controles, normalmente vía informes ISAE 3402 (Tipo I de descripción, Tipo II de operatividad). > - Las interrupciones del servicio, los cambios de configuración no autorizados y la pérdida de datos son riesgos que suelen calificar como riesgos significativos en planificación.

Cómo funciona

La nube traslada la responsabilidad física de los servidores a un tercero. Para el auditor eso supone una barrera. No puede acceder a las máquinas, ni revisar in situ los registros de control de acceso, ni verificar físicamente la segregación de funciones. La NIA-ES 315.10 le exige comprender el entorno IT de la entidad. Si ese entorno incluye un proveedor de nube, el auditor identifica qué datos residen allí, qué controles gestiona el cliente y qué controles asume el proveedor.

La NIA-ES 402 cubre el caso. Si el proveedor (Amazon Web Services, Microsoft Azure, Google Cloud o un proveedor regional) procesa transacciones que afectan a los estados financieros, el auditor no puede limitar el trabajo a los controles del cliente. Necesita evidencia sobre los controles del proveedor. Las vías habituales son dos: obtener un informe de auditor de servicios conforme a ISAE 3402, o realizar pruebas directas con credenciales del cliente sobre los sistemas alojados. En la práctica, eso significa que cuando no hay ISAE 3402 disponible (algo común con proveedores Tier 2 regionales), el equipo se queda con la opción de pruebas directas o de marcar la casilla y rezar.

Vaya por delante que los riesgos no son uniformes. Pérdida de datos por fallo de redundancia. Interrupción de servicio que impide el acceso a información contable durante el cierre. Modificación no autorizada de registros por debilidades de control de acceso. Exfiltración por brechas de seguridad. Cada uno requiere su propio procedimiento, no una respuesta genérica.

Ejemplo práctico: Constructora Andina S.A.S.

Cliente: Empresa de construcción colombiana con sede en Bogotá. Ingresos de 45 millones COP. NIIF completas.

Contexto: La entidad usa Google Workspace para correo y documentos colaborativos. Su ERP está alojado en el data center de un proveedor regional, ISOTech Latinoamérica. El director financiero asegura que ISOTech proporciona backups diarios, acceso 24/7 vía VPN y una garantía de disponibilidad del 99,5%. El auditor revisa los términos de servicio y descubre que ISOTech no tiene certificación ISAE 3402.

Paso 1: Identificar datos en la nube El auditor lista qué datos residen fuera del control directo de la entidad: el ERP (códigos de cliente, transacciones de ingresos, saldos de proveedores, asientos del diario), los correos de facturación en Google Workspace y los documentos de nómina compartidos en Google Drive. Todos pueden afectar a los estados financieros.

Nota de documentación: Inventario de sistemas en nube cerrado en la reunión de planificación. Mapa de procesos con la ubicación de los datos. Cronograma de acceso: "ERP accesible 24/7 vía VPN a 192.168.1.50. Credenciales registradas en PT-300."

Paso 2: Evaluar si se aplica la NIA-ES 402 El auditor evalúa si el proveedor encaja en la definición de "organización de servicios" de la NIA-ES 402.5. ISOTech procesa transacciones relevantes para los EEFF (mantiene el ERP donde residen ingresos y pasivos), por lo que la NIA-ES 402 se aplica.

Nota de documentación: "ISOTech = organización de servicios bajo NIA-ES 402. Requerimiento de evidencia sobre controles del proveedor. Se solicita ISAE 3402 o se planifican pruebas directas. PT-310."

Paso 3: Solicitar el informe ISAE 3402 o diseñar procedimientos alternativos El auditor pide a la dirección que obtenga un informe ISAE 3402 Tipo II de ISOTech, con pruebas de controles a lo largo de seis meses. ISOTech responde que no tiene certificación. Ofrece, en su lugar, un documento interno que describe sus controles: redundancia con servidores espejo, registro de intentos de acceso fallidos, encriptación en tránsito y rotación de contraseñas cada 90 días. No basta. Un documento interno del propio proveedor no es equivalente a una auditoría de terceros, y el socio se lo deja claro al equipo en revisión.

El auditor diseña entonces pruebas directas. Solicita el listado de accesos fallidos al ERP de los últimos dos meses y verifica que no hay patrones sospechosos. Obtiene un listado de cambios de configuración del sistema (backups, permisos de usuario) autorizados por ISOTech en los últimos seis meses y comprueba que la dirección fue notificada de cada cambio. Y prueba la recuperación: ISOTech restaura datos de hace 30 días en un servidor de prueba, el auditor verifica que el contenido coincide con los registros del cliente.

Aquí aparece la complicación. Mid-restauración, el auditor cruza el backup recuperado contra el libro diario y se encuentra que faltan asientos de las últimas 36 horas previas a la fecha de backup. El RPO documentado en el contrato es de 24 horas. La realidad operativa de ISOTech es de 48 horas. Cuando el auditor pregunta a la dirección si tiene acceso administrativo a los logs de backup de ISOTech para verificar el RPO de manera continua, la respuesta es que no. La dirección no entra en los logs del proveedor. Lo que tiene es un correo trimestral de ISOTech con capturas de pantalla. Es decir, "lo verificamos nosotros mismos" significa, en realidad, "ISOTech nos manda un PDF".

¿Y ahora qué? Vaya por delante que aquí no hay respuesta única. En mi caso, lo que veo en los encargos es que el auditor convoca al socio y planteamos tres salidas: ampliar las pruebas directas a una muestra mayor de backups y exigir un acta firmada por la dirección que reconozca el RPO real de 48h, considerar una salvedad por limitación al alcance si la dirección no acepta la ampliación, o renegociar el SLA. La constructora aceptó la primera vía. El RPO real quedó documentado en PT-322 con la firma del CFO, y el papel de trabajo cita expresamente la NIA-ES 402.9 como base.

Nota de documentación: "Pruebas de controles del proveedor realizadas. Accesos fallidos: cero en agosto, dos en septiembre (ambos con IP esperada). Cambios de configuración: seis cambios de permiso, todos notificados. Test de restauración: backup de 2024-08-15 recuperado, divergencia de 36h entre RPO contractual y RPO operativo. Acta de la dirección reconociendo RPO operativo de 48h. PT-320, PT-321, PT-322."

Paso 4: Evaluar riesgos significativos de continuidad y seguridad El auditor pregunta qué pasa si ISOTech pierde acceso a los datos: fallo de servidores espejo, ransomware, desastre natural. La dirección responde que no tiene plan de recuperación documentado con un tercero. Riesgo significativo conforme a la NIA-ES 315.34.

El auditor documenta: "riesgo significativo identificado: pérdida de datos contables por fallo de servicio del proveedor. Mitigación: ISOTech mantiene redundancia, sin contrato de DR con tercero. Procedimientos: (1) verificar que los backups se ejecutan automáticamente cada 24 horas; (2) seleccionar tres backups al azar durante el ejercicio y solicitar que ISOTech restaure uno para confirmar viabilidad; (3) revisar si la dirección ha evaluado la necesidad de un acuerdo de continuidad."

Nota de documentación: "Riesgo significativo por continuidad de datos. La probabilidad de fallo de ISOTech es baja dadas las redundancias técnicas. Test de restauración completado (PT-322). Riesgo identificado y mitigado parcialmente. Recomendación de mejora a la dirección sobre DR contractual."

Lo que auditores y revisores se equivocan

- El error de tratamiento (hallazgo de inspección): Muchos encargos tratan la nube como factor de riesgo menor y delegan la evaluación a un cuestionario administrativo. La NIA-ES 315.34 exige identificar formalmente los riesgos significativos. Si hay datos en la nube y no hay informe ISAE 3402 del proveedor, ahí hay un riesgo significativo no documentado. Los inspectores del ICAC lo vienen señalando en revisiones. Los papeles están flojos cuando faltan tanto el ISAE 3402 como las pruebas directas que lo sustituyan. Falta chicha.

- Error de alcance: El auditor obtiene un Tipo I del proveedor pero no ejecuta procedimientos sustantivos sobre los datos alojados. La NIA-ES 402.9 exige diseñar procedimientos para obtener evidencia apropiada sobre las aseveraciones afectadas por los controles del proveedor. Un Tipo I describe qué controles tiene el proveedor. No prueba que funcionen. Si la materialidad de ingresos pesa y esos ingresos pasan por el ERP del proveedor, no se puede confiar en el diseño solo. Hace falta operatividad o procedimientos sustantivos directos.

- Falta de evaluación de continuidad: Muchos encargos no evalúan si el proveedor tiene procedimientos de DR. La NIA-ES 315.23 obliga a considerar los riesgos relacionados con la continuidad de la información. Si el SLA no especifica RTO ni RPO, y la dirección no ha evaluado la implicación, ahí hay un riesgo no mitigado.

Comparación: Auditoría de sistemas locales vs. sistemas en la nube

La zona gris: cuando no hay ISAE 3402

Aquí hay una discusión honesta entre socios que merece la pena explicitar. La he oído en al menos tres firmas medianas.

El socio A sostiene que cuando el proveedor no tiene ISAE 3402, el auditor puede sustituirlo con pruebas directas: muestra de logs de acceso, revisión de cambios de configuración del periodo, test de restauración. Su argumento es que la NIA-ES 402.9 admite "procedimientos adicionales" como alternativa, y el equipo obtiene evidencia más reciente que un Tipo II que se cierra meses antes del cierre del cliente.

El socio B no lo ve igual. Dice que las pruebas directas cubren operatividad en un punto, no a lo largo del periodo. La NIA-ES 330 exige cobertura del periodo cuando se confía en controles. Un Tipo II precisamente da esa cobertura. Sustituirlo por una restauración puntual es, en su lectura, un brindis al sol.

Mi opinión, porque me la han preguntado: el socio B tiene razón en EIP y en clientes con ingresos altamente dependientes del proveedor. El socio A tiene razón en clientes pequeños donde la materialidad permite combinar pruebas directas con sustantivas amplias y no hay vía realista de exigir un Tipo II. La trampa es decidir cuál es cuál sin dejarlo registrado, porque entonces se convierte en una bomba de relojería que el inspector encuentra dos años después.

¿Y por qué los equipos aceptan un Tipo I cuando la lógica técnica pide un Tipo II? Porque el socio necesita el cliente. Porque el presupuesto de horas no contempla pruebas directas adicionales. Porque el reloj de la temporada alta no perdona, y porque escalar la decisión al socio implica una conversación incómoda sobre alcance y honorarios. No es un fallo técnico. Es un incentivo perverso. Y mientras no se nombre, sigue ahí.

Cuándo importa la distinción en un encargo

Un auditor planifica el encargo de una empresa de distribución. El sistema de gestión de inventario, donde reside la mayor parte del costo de ventas, está en servidores locales con control total de la entidad. La facturación, donde residen los ingresos, va por una aplicación SaaS de un tercero. Hay que evaluar ambos: el local bajo NIA-ES 315, la SaaS bajo NIA-ES 402. No se pueden tratar igual. Los procedimientos para verificar la exactitud de los ingresos incluyen evaluación de los controles de la SaaS, no solo revisar registros contables locales.

Términos relacionados

- ISAE 3402: El estándar internacional que rige los informes de auditor de servicios. Cuando se necesita evidencia sobre los controles de un proveedor de nube, se solicita un informe ISAE 3402 Tipo I (diseño de controles) o Tipo II (diseño y operatividad).

- NIA-ES 402: Consideraciones de auditoría relativas a entidades que usan organizaciones de servicios. Define cuándo el auditor debe evaluar controles del proveedor y qué evidencia es necesaria.

- Riesgo significativo: Un riesgo que requiere atención especial conforme a la NIA-ES 315.34. La pérdida de datos en la nube o la interrupción del servicio suelen calificar como riesgos significativos si no hay mitigaciones documentadas.

- Control de acceso: En entornos de nube, el control de acceso es responsabilidad compartida. El proveedor controla el acceso físico y la infraestructura; la entidad controla quién de su equipo accede a la aplicación.

- Segregación de funciones: En sistemas locales, el auditor verifica la segregación mediante inspección del código de aplicación o configuración de tablas de permisos. En la nube, depende de qué controles haya aplicado el proveedor y de cómo la entidad los configure.

- Continuidad del negocio: Los planes de recuperación ante desastres importan especialmente cuando los datos residentes están en manos de un proveedor. La NIA-ES 315.23 exige considerar este riesgo.

---