Audit logs
What PulsVault records in the tamper-evident organization audit log, how to filter and export it, and how to configure retention and SIEM streaming.
PulsVault keeps a tamper-evident, append-only audit log of security-relevant activity across your organization, designed for SOC 2, ISO 27001, and GDPR Article 30 evidence. This page covers what is recorded and the controls under Organization → Data & retention → Audit settings. The trail itself is read, verified and exported under Reports — see the Trace explorer and Audit & compliance.
What gets logged#
Events are grouped into streams, with about 250 distinct action types. Each entry captures the actor, IP address, user agent, correlation ID, before/after state where relevant, a severity (low → critical), and the outcome (success, failure, denied).
| Stream | Examples |
|---|---|
| Authentication | Logins, logouts, failed attempts, 2FA events |
| Data mutation | Vault/item create, edit, delete |
| Data access | Item opened, password revealed, clipboard copy |
| Sharing | Invitations and approvals, access granted, changed, left, revoked or expired, secure links, team and organisation-vault access, sharing policy changes — always recorded |
| Admin / organization | Policy changes, role changes, member management |
High-risk actions (policy changes, password changes) are written fail-closed: if the audit entry cannot be committed, the action itself is rolled back — there is no way to make a sensitive change without leaving a trace.
Tamper evidence#
Every entry is chained to the previous one: its hash covers the prior entry's hash, and each entry carries an HMAC-SHA256 signature computed with a server secret. Modifying or deleting any historical row breaks the chain, and the database itself refuses to edit any entry or to delete one less than 29 days old.
On Business and Enterprise, the chain is verified every night and on demand with Verify now, every check is kept in a verification history, and a passing check can give you a signed integrity receipt to keep outside PulsVault — see Integrity verification.
Viewing, filtering, and exporting#
Organization-scoped logs are visible to anyone whose role includes audit-read access — organization admins, the Auditor role and any custom role granted it; members see just their own activity in the My security. They can filter by stream, action, actor, severity, and date, and follow a correlation ID across all entries from a single request. On Team, Business and Enterprise plans, logs can be exported as CSV or JSON for auditors, or explored in the Trace explorer.
Sharing activity#
Reports → Sharing Activity is the audit trail pinned to who shared what, with whom, and when it ended. Its filters, deep links, row details and CSV columns are covered in Activity reports.
Sharing events are recorded however the other audit toggles are set: a record of who was given access to what is not something an organisation can switch off. Events from before sharing had its own retention setting keep their original retention window.
Configuration#
Under Organization → Data & retention → Audit settings, admins control:
| Setting | What it does | Default |
|---|---|---|
| Enable audit logging | Switches off routine activity. Sign-in and authorization events, every high or critical event in any stream, billing events and changes to these settings are always recorded | On |
| Default retention days | How long entries are kept, overriding your plan's window | Inherit plan default |
| Per-stream retention overrides | Separate retention for the auth, data-access, data-mutation, admin and sharing buckets — each governs more streams than its name suggests (auth also covers security events; data access also covers secrets operations; admin also covers authorization, tasks, billing and system). Sharing is the one control over sharing events' volume, since they are always recorded | Inherit default |
| Log password access | A plaintext password revealed or copied to the clipboard | On |
| Log vault mutations | Every change to vaults, items, notes and folders — created, updated, deleted, restored, archived, imported — and key rotations. Turning it off also stops item and note history | On |
| Log item access events | An item or note opened for viewing, and a vault opened | On |
| Log item export events | Bulk exports of an item or a whole vault, and attachment downloads | On |
| HMAC sensitive fields | Record sensitive details (keys, tokens) as an HMAC digest instead of [REDACTED], so one value can be followed across entries during an investigation. The digest is the same every time for the same value, so it can be correlated where [REDACTED] reveals nothing |
On |
| SIEM webhook URL + signing secret | Stream events to your SIEM, signed so you can verify origin (Business and above) | Off |
| Weekly security report | Email the security posture digest to report readers every Monday | Off |
Retention defaults scale with plan — 30 days on Free, 90 days on Premium and Developer, 1 year on Family and Team, 7 years on Business, and unlimited on Enterprise. A nightly job purges entries past their retention window.
An override may deliberately exceed your plan's window — audit volume is low and keeping more is harmless. It may not go below 30 days, and it may not be cleared by leaving the field blank: use Inherit plan default to remove one.
Match per-stream retention to your framework: keep admin and authentication streams longest, and consider shorter windows for high-volume data-access events.
The weekly security report#
Off by default. Turn it on under Data & retention → Audit settings → Weekly Security Report, and every Monday at 08:00 the people who can read your organization's security report are emailed a digest of it.
It carries your organization score and how it moved over the past week, how many members have no second factor, how many have never run an analysis, and how many credentials are weak, reused, aging or found in a breach.
Two things it deliberately does not do:
- It does not send on a quiet week. If nothing is outstanding and nothing moved, no email goes out. A weekly message that says nothing teaches people to filter it, and then the one that matters is filtered too.
- It never names a credential. Counts and dates only — never which credential is weak, its name or its value. Those are encrypted on your members' own devices and have never reached our servers, and an inbox is forwardable and outside every permission check this product enforces.
A score you have not measured is reported as not measured yet, never as zero, and on a plan without breach monitoring the email says the breach count is not monitored rather than reporting none.
Recipients are resolved at send time from who holds report-read access, so a member who gains or loses it is added to or dropped from the next Monday's send without anyone maintaining a list.
SIEM event streaming#
Available on Business and above. Every audit event is POSTed to your endpoint as it is recorded.
- Under Organization → Data & retention → Audit settings, set the Webhook Endpoint URL. It must be HTTPS and publicly resolvable — the API refuses private and loopback addresses.
- Set a Webhook Signing Secret. Each request then carries
X-Audit-Signature: sha256=<hex>, an HMAC-SHA256 of the exact request body. - Verify that header on your side before trusting a payload. Without a secret, events are sent unsigned.
The secret is write-only: once saved it is never shown again, and the settings screen reports only whether one is configured. Replace it by typing a new one; remove it with Remove signing secret.
Streaming is asynchronous, and a failure to deliver is logged rather than retried — a SIEM outage can never fail a login or a secret read. Your audit log remains the system of record; the stream is a copy. Clearing the URL stops streaming and removes the stored secret with it.
Related#
- Audit log architecture — hash-chain design for security reviewers
- Audit & compliance reports — packaged evidence reports
- Roles & permissions — who may read organization logs