Packaging knowledge
Audit and traceability
Who changed which package when: which events are recorded and what they answer when something goes wrong.
What an audit answers
Not “who is to blame”, but “which version was on which device, when, and who changed it”. That is the question that matters during an incident — and the one you cannot answer without a record.
Events and metadata
A useful audit records three things: the action (created, changed, exported, assigned), the timestamp and the actor. Plus package metadata: name, version, source.
In PilotDeploy, audit events and controlled metadata storage are enterprise features.
Limits of logging
An audit shows what happened, not whether it was right. It replaces neither approval, nor testing, nor backup. Mistake it for an approval tool and you log errors instead of preventing them.
Retention
How long events are kept is an organisational decision, not a technical one. Six months may suffice in many environments; regulated areas need much longer. What matters is deciding before the incident, not after.
Preparing for a review
Three questions an audit must answer: which package version ran on the reference date? Who approved it? What changed afterwards? If you cannot answer those three, you have a log, not an audit.
---
Small environment, small audit
Not every environment needs a full audit system. Three questions and one place where they are answered often suffice: which version, who changed it, when. The gap between “no audit” and “a simple audit” is bigger than between “simple” and “complete”.