Compliance
Audit trail
An audit trail is the chronological, tamper-evident record of who did what, when, and to which system or piece of data. It is built up from log entries, timestamps, and change records well enough that a specific sequence of events can be reconstructed and verified after the fact, whether that is for a security investigation, a compliance audit, a financial reconciliation, or a legal dispute.
Why Audit trail matters in a Microsoft estate
Audit trail matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.
How Audit trail shows up in practice
The concept is broader than any single product's logging feature. In a Microsoft 365 and Azure estate, an organisation's effective audit trail is typically assembled from several distinct sources working together: the Microsoft 365 unified audit log for user and admin activity, Entra ID sign-in and audit logs for authentication and identity changes, Azure Activity Log and Azure Monitor for resource-level changes across subscriptions, and, where used, third-party licence, cost, or configuration management tooling that records changes to entitlements, spend, or policy independently of Microsoft's own logging. What separates a genuinely useful audit trail from a simple activity feed is a small set of properties.
These are completeness (no meaningful gaps where activity went unrecorded), integrity (confidence that entries have not been altered or deleted after the fact, often through write-once storage, immutable logging, or cryptographic hashing), sufficient retention to cover the period an investigation or audit might realistically need to look back over, and enough context in each entry, actor, action, target, timestamp, and outcome, that it is actually interpretable months later without requiring the original administrator's memory to fill in gaps. A common and costly failure pattern is discovering the audit trail is incomplete only during an actual investigation or dispute. Logging was enabled for some systems but not others, retention had already lapsed for the relevant window, or the record shows that an action happened but not who authorised it or why.
All of these erode the evidentiary value of the trail precisely when it is needed most. Audit trails sit at the centre of most compliance frameworks relevant to Microsoft-estate operators, including ISO/IEC 27001, ISO 22301, SOC 2, and Cyber Essentials. This is not a checkbox requirement, but because they are the mechanism by which an organisation demonstrates that its stated access control, change management, and incident response processes are actually being followed in practice, rather than existing only as policy documents. This is why auditors and assessors will typically ask to see specific trail entries corresponding to specific claimed controls, rather than accepting the existence of logging in the abstract.