[Blog]()Auditoría de cambios # Bitácora de cambios: quién cambió qué y cómo investigar una diferencia Una fecha y un usuario no explican una diferencia. Necesitas encontrar el cambio, su origen y el resultado que dejó en el negocio. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Una bitácora útil identifica el registro afectado, quién actuó, cuándo ocurrió, qué cambió y qué decisión lo autorizó cuando corresponda. Debe permitir comparar el valor anterior y el nuevo sin exponer secretos innecesarios. Pruébala reconstruyendo una diferencia concreta, incluidos intentos rechazados y cambios de una integración. ## Hoja de prueba: Bitácora de cambios: investigar una diferencia Una fecha y un usuario no explican una diferencia. Necesitas encontrar el cambio, su origen y el resultado que dejó en el negocio. Registra datos, resultado esperado, evidencia, responsable y resultado observado. [Descargar hoja CSV]() En esta guía - [Empieza por una diferencia que necesites explicar]() - [Ejemplo ficticio: precio de compra en OC-404]() - [Comprueba el historial, no solo el cambio]() - [Decide qué conservar y qué no incluir]() - [Usa una diferencia para aceptar la herramienta]() ## Empieza por una diferencia que necesites explicar En una fábrica, compras puede preguntar por qué el costo del pedido cambió después de su autorización. En una empresa de servicios, operación necesita saber quién cerró una orden sin su evidencia. Define esas preguntas antes de pedir «guardar todos los eventos». Un historial inmenso que no permite encontrar el registro o su secuencia tampoco ayuda a resolver el caso. [Dataverse]() documenta que la auditoría depende de su activación y que algunos registros pueden aparecer con retraso. [OWASP]() recomienda proteger los registros y excluir información sensible innecesaria. La prueba debe comprobar cobertura y disponibilidad reales: una pantalla llamada bitácora no demuestra que cada campo relevante se esté registrando. ## Ejemplo ficticio: precio de compra en OC-404 El pedido OC-404 contiene 300 unidades a 12 MXN. Una persona propone cambiar el precio a 14 y finanzas lo autoriza. El importe pasa de 3,600 a 4,200 MXN, antes de impuestos u otros conceptos. La diferencia es 600 MXN. Este ejemplo sintético sirve para reconstruir un cambio; no representa compras ni resultados de un cliente. El historial esperado muestra el pedido y su versión, precio 12→14, cantidad 300, solicitante, aprobador y motivo. Si un conector ejecuta el cambio, distingue su identidad técnica de la persona o regla que originó la solicitud. «API» como único autor puede ser insuficiente para explicar una decisión comercial; acuerda qué referencia enlazará el cambio con su origen. | Dato |Para qué sirve |Cuidado necesario | | --- | --- | --- | | Registro y versión |Ubicar OC-404 y el estado revisado |No depender solo de un nombre editable | | Antes y después |Explicar precio 12→14 e importe |Registrar solo campos pertinentes | | Actor y origen |Distinguir usuario, aplicación y aprobación |No registrar contraseñas ni tokens | | Hora y referencia relacionada |Ordenar cambio, autorización y reintento |Anotar zona horaria y relojes relevantes | ## Comprueba el historial, no solo el cambio Ejecuta el ensayo con usuarios autorizados y datos ficticios. Busca el registro desde la operación y desde la bitácora. Verifica que un usuario sin permiso no pueda cambiar el historial o consultar información que no necesita. Si los eventos llegan después, mide ese retraso y define cómo se mostrará un resultado todavía pendiente. | Caso |Resultado esperado |Evidencia | | --- | --- | --- | | Precio autorizado 12→14 |Antes, después y aprobación localizables |OC-404 y evento relacionado | | Intento de cambio sin permiso |Precio sin cambio; intento identificable según alcance acordado |Solicitud rechazada y estado final | | Cambio hecho por conector |Identidad técnica y referencia de origen distinguibles |Evento y solicitud original | | Reintento tras perder respuesta |No parece otra decisión comercial independiente |Referencia común y secuencia | | Usuario intenta editar historial |Edición rechazada con control verificable |Permiso y resultado | | Campo relevante no tiene auditoría activa |Hueco visible; prueba no aprobada |Configuración y ausencia comprobada | ## Decide qué conservar y qué no incluir No guardes secretos, datos completos de tarjetas ni documentos personales en un registro solo por comodidad. El motivo de un cambio puede contener información sensible si se admite texto libre; revisa permisos y límites de ese campo. Una referencia al documento autorizado puede ser mejor que copiarlo completo en cada evento. La conservación depende del negocio, almacenamiento y obligaciones aplicables. Define quién consulta, quién administra retención y quién detecta interrupciones del registro. Una bitácora técnica no se convierte automáticamente en evidencia legal suficiente, ni garantiza descubrir toda modificación. Si necesitas una revisión especializada, acota el propósito y el sistema que realmente registra cada acción. ## Usa una diferencia para aceptar la herramienta Pide a una persona que no presenció el ensayo reconstruir qué ocurrió en OC-404. Si necesita interrogar al equipo porque faltan origen o versión, la bitácora todavía no cumple esa tarea. Relaciona la prueba con [roles y permisos](), las [reglas de sincronización]() y la [conexión de tu ERP](). La hoja contiene diez casos para anotar evidencia y responsables. En una [consulta gratuita]() de [ciberseguridad](), trae una diferencia anonimizada, los campos que necesitas explicar y las opciones de historial de tu sistema. Podemos revisar qué ya puede verificarse y qué parte requiere configuración o una evaluación adicional. ## Revisemos una diferencia y su historial Parte de una diferencia anonimizada y su registro original. En una consulta gratuita podemos revisar qué datos del historial existen, cuáles faltan y qué retención o permisos necesitas para investigar sin borrar la evidencia. - Una diferencia anonimizada con el registro original - Campos, usuarios e integraciones que deben explicarse - Opciones actuales de auditoría, retención y consulta [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Ciberseguridad para empresas]() - [Hosting, respaldos y mantenimiento]() ## Preguntas frecuentes ### ¿Debo registrar cada consulta de datos? Depende de la pregunta que necesites responder y del alcance disponible. Consultas, exportaciones y cambios son acciones distintas. Acuerda cuáles son relevantes y comprueba su cobertura; registrar demasiado también puede añadir datos sensibles y dificultar la investigación. ### ¿Una bitácora evita que alguien cambie datos? El historial y la autorización cumplen tareas distintas. Los permisos pueden impedir una acción; la bitácora ayuda a reconstruirla. Necesitas probar ambos y proteger el historial. No lo presentes como una garantía contra cualquier modificación. ### ¿Qué hago si el autor aparece como integración? Conserva la identidad de la aplicación y una referencia que permita encontrar la solicitud, regla o persona de origen cuando exista. No atribuyas automáticamente la decisión a quien instaló el conector. Define cómo se reconstruye esa cadena. ### ¿Qué demuestra una ausencia de eventos? Primero comprueba que el campo estaba cubierto, la prueba se ejecutó y no hay retraso pendiente. La ausencia puede indicar un hueco de configuración o retención, no que nunca hubo un cambio. Registra el límite en lugar de inventar una conclusión. ## Fuentes 1. [Manage Dataverse auditing]()Microsoft 2. [Logging Cheat Sheet]()OWASP Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Permisos internos8 oct 2026 ### Roles y permisos: quién consulta, cambia y autoriza en tu sistema]()[Eventos de integración8 oct 2026 ### Webhooks que fallan: reintentos sin duplicar trabajo ni perder eventos]()[Conflictos de datos8 oct 2026 ### Sincronizar datos: decidir qué hacer cuando dos personas cambian lo mismo]() --- Canonical: https://nightlysoftware.com/blog/bitacora-auditoria-cambios Updated: 2026-10-08 Description: Reconstruye cambios de precio, cantidad o estado con usuario, versión y evidencia. Incluye pruebas para una bitácora útil en tu operación.