audit logging.
Audit logging records who did what, when, and to which record — an immutable trail of actions taken, kept for compliance, investigation and accountability rather than for debugging.
Where audit logging fits on a long engagement.
Audit logs answer different questions from application logs and have different requirements. They must be immutable, complete for the actions in scope, and retained for a defined period — and they are read by auditors and investigators rather than by engineers debugging.
Completeness is the requirement that is hardest to meet. An audit trail capturing user interface actions but missing changes made through an API, a batch job or direct database access is incomplete in exactly the ways an investigation cares about.
What an assigned team does with audit logging.
Immutability has to be enforced rather than intended. If an administrator can delete audit records, the trail proves nothing about an administrator's actions — which is frequently the case an audit exists to examine.
Append-only storage with separated access control is what makes it meaningful, and it is designed in as part of the standards described in how an assignment runs.
What we use audit logging for.
- A trail that covers every path Interface, API and batch changes all recorded, not only the ones users see.
- Immutability enforced technically Append-only storage, so the trail proves something about privileged actions.
- Retention matched to obligation A defined period aligned to the actual regulatory requirement.
How audit logging capacity is assigned.
Audit capability is assigned inside the discipline that owns the data, with completeness across every write path treated as the requirement.
Tell us what your roadmap needs audit logging for.
A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.
Loading the contact form… You can also email hello@azendo.co.
We reply within one working day. No obligation, and no newsletter.