[Blog]()Change auditing # Change audit logs: who changed what and how to investigate a difference A date and username do not explain a difference. Find the change, its origin and the business outcome it produced. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** A useful audit log identifies the affected record, actor, time, change and authorizing decision where relevant. It should compare previous and new values without exposing unnecessary secrets. Test it by reconstructing a specific difference, including rejected attempts and integration changes. ## Test worksheet: Change audit logs: investigating a business difference A date and username do not explain a difference. Find the change, its origin and the business outcome it produced. Record inputs, expected outcome, evidence, owner and observed result. [Download CSV worksheet]() In this guide - [Start with a difference you need to explain]() - [Fictional example: purchase price on PO-404]() - [Verify the history, not just the edit]() - [Decide what to retain and what to exclude]() - [Accept the tool through one reconstructed difference]() ## Start with a difference you need to explain In a factory, purchasing may ask why an order cost changed after approval. In a service company, operations may need to know who closed an order without evidence. Define those questions before requesting “all events.” An enormous history that cannot locate a record or sequence is not useful for resolving the case either. [Dataverse]() documents that auditing depends on activation and some records may appear with a delay. [OWASP]() recommends protecting logs and excluding unnecessary sensitive information. Test actual coverage and availability: a screen named audit log does not establish that every relevant field is recorded. ## Fictional example: purchase price on PO-404 Order PO-404 contains 300 units at 12 MXN. Someone proposes a price of 14 and finance approves. The amount changes from 3,600 to 4,200 MXN before taxes or other components. The difference is 600 MXN. This synthetic example supports reconstructing a change; it is not a customer's purchase or result. The expected history shows order and version, price 12→14, quantity 300, requester, approver and reason. If a connector applies the change, distinguish its technical identity from the person or rule that initiated it. “API” alone may not explain a sales decision; agree which reference links the change to its origin. | Data |Purpose |Necessary care | | --- | --- | --- | | Record and version |Locate PO-404 and the reviewed state |Do not rely on an editable name | | Before and after |Explain price 12→14 and amount |Record relevant fields only | | Actor and origin |Distinguish user, application and approval |Never record passwords or tokens | | Time and related reference |Sequence change, approval and retry |Note time zone and relevant clocks | ## Verify the history, not just the edit Run the rehearsal with authorized users and fictional data. Find the record through operations and through audit history. Check that an unauthorized user cannot alter history or view information they do not need. If events arrive later, measure that delay and define how a still-pending result will be shown. | Case |Expected result |Evidence | | --- | --- | --- | | Authorized price change 12→14 |Before, after and approval can be located |PO-404 and related event | | Unauthorized change attempt |Unchanged price; identifiable attempt under agreed scope |Denied request and final state | | Connector applies change |Technical identity and origin reference distinguishable |Event and original request | | Retry after lost response |Not mistaken for another independent business decision |Shared reference and sequence | | User attempts history edit |Denied through verifiable control |Permission and outcome | | Relevant field has auditing disabled |Visible coverage gap; test not passed |Configuration and verified absence | ## Decide what to retain and what to exclude Do not log secrets, full card data or personal documents merely for convenience. A free-text change reason may contain sensitive information; review access and limits for that field. A reference to an authorized document can be preferable to copying the full document into every event. Retention depends on business needs, storage and applicable obligations. Define who reads history, who manages retention and who detects logging interruptions. A technical log does not automatically become sufficient legal evidence or guarantee discovery of every edit. If specialist review is needed, define its purpose and which system actually records each action. ## Accept the tool through one reconstructed difference Ask someone who did not witness the rehearsal to reconstruct PO-404. If they must interview the team because origin or version is missing, the log has not yet met that task. Connect the test with [roles and permissions](), [synchronization rules]() and [ERP connections](). The worksheet contains ten cases for evidence and owners. For a [free consultation]() on [cybersecurity](), bring an anonymized difference, the fields you need to explain and current history options. We can review what is already verifiable and what needs configuration or additional evaluation. ## Review a difference and its change history Start with an anonymized difference and its original record. In a free consultation, review which history exists, what is missing, and the retention or access rules needed to investigate while preserving evidence. - One anonymized difference with its original record - Fields, users and integrations that need explanation - Current audit, retention and history-access options [Book a free consultation]()[Ask on WhatsApp]() Related - [Cybersecurity for businesses]() - [Hosting, backups and maintenance]() ## Frequently asked questions ### Should every data read be logged? It depends on the question and available scope. Reads, exports and changes are different actions. Agree which matter and test their coverage. Excessive logging may introduce sensitive data and make investigation harder. ### Does an audit log prevent edits? History and authorization have different jobs. Permissions can prevent an action; a log helps reconstruct it. Test both and protect history. Do not present logging as a guarantee against any possible modification. ### What if the actor is an integration? Retain the application identity and a reference to its originating request, rule or person where available. Do not automatically attribute a decision to the person who installed the connector. Define how that chain can be reconstructed. ### What does an absence of events prove? First verify that the field was covered, the test ran and no delay remains pending. Absence may indicate a configuration or retention gap, rather than proving that a change never occurred. Record the limitation instead of inventing a conclusion. ## Sources 1. [Manage Dataverse auditing]()Microsoft 2. [Logging Cheat Sheet]()OWASP Last updated: October 8, 2026 ## Keep reading [Internal permissionsOct 8, 2026 ### Roles and permissions: who views, changes and approves in your system]()[Integration eventsOct 8, 2026 ### Failing webhooks: retrying without duplicate work or lost events]()[Data conflictsOct 8, 2026 ### Synchronizing data: deciding when two people change the same field]() --- Canonical: https://nightlysoftware.com/en/blog/business-change-audit-log Updated: 2026-10-08 Description: Reconstruct price, quantity or status changes with actor, version and evidence. Includes tests for an audit log that supports your operation.