# Auditoría y regulación: una rendición de cuentas que usted puede demostrar · Stilla > Un auditor no pregunta si usted tiene un proceso, sino si puede mostrar quién hizo qué, cuándo y quién lo aprobó. URL: https://stilla.eywo.digital/es/blog/audit-and-accountability/ Language: es Last updated: 2026-10-25 [← Volver al blog](https://stilla.eywo.digital/es/blog/) Gobernanza8 de octubre de 2026Actualizado 25 de octubre de 20264 min readEquipo de Eywo # Auditoría y regulación: una rendición de cuentas que usted puede demostrar Un auditor no pregunta si usted tiene un proceso, sino si puede mostrar quién hizo qué, cuándo y quién lo aprobó. A continuación, se explica cómo tener las respuestas listas antes de que llegue la pregunta. En muchos departamentos de TI, las semanas previas a una auditoría siguen el mismo ritual. Varias personas dejan de lado su trabajo habitual y reúnen pruebas. ¿Quién aprobó este cambio? ¿Por qué este usuario tenía derechos de administrador? ¿Cuándo cambió la configuración del firewall y quién la cambió? Las respuestas existen, pero están dispersas en correos electrónicos, chats, exportaciones de diferentes herramientas y en la memoria de las personas, algunas de las cuales ya han dejado la empresa. Al mismo tiempo, la presión para proporcionar pruebas sigue aumentando. La regulación de ciberseguridad, como NIS2 y la legislación nacional que la implementa, generalmente pone énfasis en la gestión de riesgos, la responsabilidad de la gestión y la capacidad de demostrar que las medidas de seguridad realmente funcionan. Las obligaciones específicas difieren según el tipo de organización y se evalúan mejor con especialistas legales o de cumplimiento. Sin embargo, el hilo conductor es claro: hacer las cosas bien no es suficiente. Debe poder probarlo. ## Por qué reunir pruebas después del hecho falla El problema rara vez es que una organización no tenga procesos. El problema es que esos procesos no dejan un rastro por sí mismos. - **Las aprobaciones ocurren fuera del sistema.** El consentimiento para un tiempo de inactividad llega por correo electrónico, el cambio se realiza en otro lugar y el vínculo entre ellos solo existe en la cabeza del gestor de cambios. - **El historial se sobrescribe.** La herramienta muestra el estado actual, pero no cómo era antes. - **Las acciones automatizadas son invisibles.** Los trabajos programados cambian los datos, pero nadie sabe exactamente cuándo ni qué hicieron. - **Las responsabilidades viven en papel.** Una matriz RACI se encuentra en un documento y nadie verifica si coincide con los permisos reales. El resultado es una auditoría que se ejecuta como un proyecto, en lugar de una auditoría como una revisión rutinaria de los registros. ## Cómo abordar la probabilidad La verdadera preparación para la auditoría es un subproducto del trabajo diario. Si cada acción ocurre en un sistema que la registra, la prueba existe en el momento en que suceden las cosas. Algunos principios: - registrar no solo "quién y cuándo" sino también "qué cambió exactamente", es decir, el estado antes y después, - auditar lo que hacen las máquinas, no solo lo que hacen las personas, - mantener registros durante el tiempo suficiente, - describir responsabilidades de una manera que pueda compararse con los permisos reales. ## Cómo lo maneja Stilla Stilla mantiene un registro de auditoría de todas las acciones, retenido durante cinco años. Para los cambios de configuración, registra el estado antes y después, para que pueda ver no solo que algo cambió sino exactamente qué. Las acciones del programador, los trabajos automatizados que se ejecutan sin intervención humana, también se auditan. Los elementos de la CMDB tienen su propia historial de versiones. Para cada cambio, puede ver quién lo hizo, cuándo, qué cambió y de dónde vino: la API de descubrimiento, una importación, una edición manual o la sincronización con una CMDB primaria. Las aprobaciones ocurren dentro del sistema. Los tiempos de inactividad en cambios, solicitudes y otros elementos que necesitan una decisión se unen en una sola cola de "Para aprobación". Una regla define quién es el propietario y un rechazo siempre viene con una razón. El registro de quién acordó qué se crea junto con el cambio. Las responsabilidades se describen en una matriz RACI y Stilla verifica que sea consistente con los permisos. Si alguien está listado como responsable pero no tiene un rol que le permita aprobar o realizar la tarea, se muestra. Los roles están definidos (todo, cliente, equipo, elemento), por lo que está claro no solo qué puede hacer alguien sino también sobre qué. ## Conclusión Una auditoría no debe ser un proyecto. Cuando el registro de auditoría se crea automáticamente, las aprobaciones viven en el sistema y las responsabilidades están vinculadas a los permisos, la respuesta a una pregunta de un auditor está a unos pocos clics de distancia. El equipo sigue trabajando y la gerencia puede estar segura de que se puede demostrar la responsabilidad. El registro de auditoría, el historial de la CMDB y la matriz RACI están incluidos en la edición Estándar. **Stilla Standard** Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados. [Comparar ediciones →](https://stilla.eywo.digital/es/editions/) ## Más artículos [Gobernanza·25 de octubre de 2026 ### NIS2 y DORA: lo que las operaciones de TI deben poder demostrar Ambas regulaciones formulan la misma pregunta: ¿sabe qué servicios se ven afectados por una interrupción, quién es responsable de ellos y qué cambió cuándo? Sin un mapa de dependencias fiable, las respuestas se elaboran manualmente, a menudo bajo presión de tiempo. Standard3 min read](https://stilla.eywo.digital/es/blog/nis2-dora-evidence/)[Gobernanza·17 de septiembre de 2026 ### Plataforma compartida, datos de clientes separados Un proveedor de servicios compartidos necesita una plataforma para cada cliente, mientras que cada cliente solo quiere ver sus propios servidores, incidencias y costes. A continuación, se explica cómo lograr ambos sin comprometer la seguridad. Enterprise4 min read](https://stilla.eywo.digital/es/blog/shared-platform-separated-data/)[Gobernanza·25 de junio de 2026 ### ¿Quién es el propietario de este servicio? Responsabilidad que puede rastrear Cuando nadie está seguro de quién es responsable de un servicio, los cambios se retrasan, las incidencias se trasladan entre equipos y las aprobaciones se estancan. La propiedad clara es la base sobre la que se apoya el resto de las operaciones. Standard3 min read](https://stilla.eywo.digital/es/blog/who-owns-the-service/)