BlogChange 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.
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.
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.
Frequently asked questions
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.
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.
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.
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
- Manage Dataverse auditingMicrosoft
- Logging Cheat SheetOWASP
Last updated: