What an audit trail for shared secrets should record
The events to log when you share passwords and keys (created, opened, by whom, failed attempts, burned, expired), what never to log, and how long to keep it.
On this page
An audit trail for shared secrets should let you answer five questions about any secret: who created it and under what rules, who it was meant for, who opened it and from where, what failed along the way, and how it ended. It must never contain the secret, or anything that would let someone open it.
That second rule is easy to break by accident. Plenty of homegrown handover processes “log” by keeping the email or chat message the password was sent in, and the log becomes the leak.
The events to record
| Event | Why you want it | Fields worth keeping |
|---|---|---|
| Created | Establishes the owner and the rules the secret was sent under | Who, when, an internal reference to the secret, expiry, view limit, passcode or recipient restrictions |
| Sent to recipients | Records who it was meant for, so you can compare that with who opened it | Recipient addresses, delivery result |
| Opened | The event that matters most if something later leaks | When, who (or "anonymous"), which recipient, IP address, user agent, views remaining |
| Failed open | Wrong passcode, not signed in, not a listed recipient. Bursts of these are worth a look. | Reason, when, IP address |
| Destroyed by failures | Too many wrong passcodes, so the secret was deleted unread | Number of attempts, when |
| Burned | Deliberately destroyed early, and by whom | Who, and whether it was the owner, the recipient or an administrator |
| Expired unopened | Often the most useful signal of all: the handover didn't happen, and the credential may have gone some other way | Expiry time |
Around the secrets themselves, log the events that change who can do what: sign-ins and failed sign-ins, two-factor authentication turned on or off, members invited, removed or given a new role, API keys created and revoked, policy changes, and exports of the audit log itself. An attacker who wants to read secrets quietly will usually touch one of these first.
What never to log
- The secret. Not in the event, not in a debug log, not in an error report.
- Anything derived from it. A hash of a password lets anyone with the log test guesses against it.
- The link or its token. Until it has been opened, a secret link is a working credential. Log an internal reference instead, one that can’t be used to open anything.
- Passcodes, verification codes and burn tokens. Same reasoning.
- Request bodies. Logging the whole request “for debugging” is how secrets end up in log storage.
Labels deserve a second thought too. People type things like “root password for prod-db-2” into a label field. That isn’t the secret, but it tells a reader which system to attack. Decide whether labels belong in exported logs.
How long to keep it
Keep two retention periods in mind, because they pull in different directions.
The events. Keep them for at least as long as the period your audits look back over, plus enough margin to investigate an incident discovered late. An ISO/IEC 27001 surveillance audit looks at the year since the last visit, and a SOC 2 Type II report covers a defined observation period. Annex A 8.15 asks for logs to be produced, stored, protected and analysed, and the compliance mapping shows where else they come up.
The personal data inside them. IP addresses and user agents are personal data under UK GDPR. They’re very useful for a few months, while an investigation is likely, and much less useful after that. Data minimisation (Article 5(1)(c)) and storage limitation (Article 5(1)(e)) argue for keeping the event and dropping the identifiers once they’ve stopped earning their place.
Making the log trustworthy
- Append-only. Nobody, administrators included, should be able to edit or delete individual events through the product.
- Narrow access. Reading the log should be limited to the people who need it, and exporting it should be narrower still and itself logged.
- Accurate time. Every event is only as good as its timestamp. Annex A 8.17 covers clock synchronisation for this reason.
- Get it out. If you run a SIEM, export regularly so the log survives a compromise of the tool that produced it.
What to look for when you review it
- A secret opened from a network or country you don’t expect, or long after it was sent.
- A secret opened before the intended recipient says they received it. Treat the credential as leaked and change it.
- Repeated failed opens or passcode lockouts on the same secret.
- Secrets that expired unopened, followed by the recipient saying they have access anyway.
- Administrators burning other people’s secrets, or exporting the log, without a ticket to explain it.
How ShareShield’s audit log maps to this
ShareShield’s audit log records secret created, secret emailed to recipients, recipient verified by email code, secret opened (with the recipient’s address where there is one, and the views remaining), secret open failed (with the reason), secret locked out after too many wrong passcodes, and secret burned (by its owner, its recipient’s burn link or an organisation administrator). Requests, members, API keys, organisation settings, billing, sign-ins, 2FA, SSO, domains and audit log exports are recorded alongside.
A few specifics, so you know exactly what you’re getting:
- Expiry isn’t an event. A secret that expires unopened shows as expired in the dashboard, and its content is deleted, but no audit event is written for the expiry itself. If you report on unopened handovers, use the secret’s status.
- Events point to an internal record id, not the link, so the log can’t be used to open a secret. Secret content, passcodes and tokens are never written to it.
- IP addresses and user agents are stored for investigation, with IPv6 addresses cut to their /64 network. Both are cleared from events older than 90 days; the events themselves are kept.
- Access. Owners and admins can read the log in the dashboard, filtering by category, event, actor and date range. Owners of Professional and Enterprise organisations can export it as CSV, and every export is itself recorded.
If you’re deciding what your own policy should say about how secrets are sent in the first place, start with one-time links vs password managers.
Send the next one as a link that expires.
ShareShield turns a password, key or file into a link that opens once and is then deleted. You can send a text secret without an account.