A secrets audit log should record who requested a secret and for which system, whether the request was approved, when the secret was used and by what, when it expired or changed, and any failed attempts. It must also resist tampering and carry accurate timestamps.
The minimum list
The OWASP Secrets Management cheat sheet gives a list of what to audit at a minimum:
| Event | Why it matters to a payments team |
|---|---|
| Who requested a secret, for which system and role | Shows whether access matches job duties |
| Whether the request was approved or rejected | Evidence that approval controls work |
| When the secret was used and by whom or what | Lets you trace a suspicious payment action |
| When the secret expired | Proves expiry is enforced |
| Attempts to reuse expired secrets | An early sign of a stale or stolen credential |
| Authentication and authorization errors | Brute force and misconfiguration both show up here |
| When the secret was updated and by whom | Change accountability |
| Administrative actions on the supporting infrastructure | The people who run the vault are also a risk |
Make the log hard to tamper with
OWASP stresses that auditing must be implemented securely so it resists attempts to tamper with or delete the logs. In practice that means shipping logs to a separate account or system that the secrets administrators cannot edit, and restricting who can read them.
Timestamps need care too. The guidance says all auditing needs correct timestamps and that the secrets system should use proper time synchronization on its supporting infrastructure. Without that, you cannot line up a secret read against a transaction log during an investigation.
Log the pipeline as well
Attackers can use CI/CD tooling to extract secrets, for example through job creation that exfiltrates a value using encoding tricks. OWASP therefore says to log every action in a CI/CD tool and to alert on non-standard manipulation of the pipeline or its admin interface. It suggests logs be queryable for at least 90 days and stored longer in cold storage.
The same section asks that a pipeline run be attributable to the person who defined or triggered the job. A shared service account that anyone can trigger makes that impossible.
What not to log
Never write the secret value itself into the audit trail. Log identifiers, outcomes and the requesting principal. This sounds obvious until a debug flag dumps a request body. The OWASP payment gateway guidance makes a related point for payment events: log callback identifiers and validation results rather than raw headers and bodies, and exclude credentials and unnecessary payment data.
A short build plan
- Pick the system of record for secrets and turn on its native audit trail.
- Forward the trail to storage that secrets administrators cannot modify.
- Define alerts for failed access, use of expired secrets and out of hours administrative actions.
- Review a sample of entries monthly and write down what you checked.
- Practice an investigation: pick one secret and reconstruct who touched it over the last month.
Step 5 is the one that finds the gaps. If you cannot answer in an hour, the log is not yet useful.
Where Safeguard fits
Safeguard does not store secrets. Its compliance and evidence automation can collect dated records of the controls you operate, such as pipeline policy results, so your review notes are not assembled by hand. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a control and see how one piece of audit evidence can support several requirements.
Quick check
How long should CI/CD logs be kept?
OWASP suggests logs be queryable for at least 90 days and kept longer in cold storage. Your own retention needs may be longer, so confirm them with your compliance owner.
Should the audit log include the secret value?
No. Record identifiers, who, what and the outcome, never the value.
Sources
Last reviewed: 19 October 2026.
