Audit and Compliance
An append-only record of who did what, to which record, from which address — for your organization and, if you use one, for the MSP that manages you.
How Solidlio helps
The actor’s email and role are copied in at write time, so a record stays attributable after that person leaves and their account is deleted. Nothing in the product can edit or delete an entry — no API route on any service exposes an update or delete verb for one — and the only path that removes entries is a retention purge that is off until you set a window and that skips any tenant under legal hold. Co-management events are written to both sides, so you can show when an MSP’s access to your data began and ended without asking that MSP for its logs.
Capabilities
| Capability | What it does |
|---|---|
| Unified activity trail | Authentication, assets, network, billing, integrations and co-management in one searchable record |
| Actor that survives | Email and role are copied in at write time, so a deleted user’s actions stay attributable |
| Before/after payloads | Field-level diffs on updates — the old value and the new one, per field |
| Secret redaction | Passwords, tokens, API keys and card numbers are stored as [redacted], never as values |
| Tenant isolation | Every read is pinned to the caller’s organization and account, including searches and detail lookups |
| Administrator-only | organization administrator and above. Standard users cannot read colleagues’ login times, addresses or agents |
| Auditor export | Server-side CSV or JSON over any date range, up to 50,000 rows — and the export is itself recorded |
| User lifecycle | Provisioning, edits, deactivation, deletion and every role grant and revocation, actor and target named |
| Immutability | No update or delete verb exists on any audit route, on any service |
| Legal hold | Suspends retention deletion for one tenant while a matter is live; the hold record is kept after release |
| Retention control | Opt-in window, batched purge, reported cutoff and eligible-row count before anything is deleted |
| 33 security events | Logins, failures, MFA, recovery codes, password changes, session revocations, user lifecycle, exports |
| ITIL change record | 25 change action types including every approval decision, authority resolution and quorum event |
| Platform separation | Platform-operator actions are recorded in a separate trail a tenant administrator cannot influence |
Built for MSPs and their clients
Audit is where co-management is most often unverifiable — and where it matters most. Solidlio writes co-management events to both parties.
| Organization | MSP | |
|---|---|---|
| Own activity trail | Its own, in its own portal | Its own, plus each managed client’s |
| MSP access grants | Sees when access was granted, by whom, and revoked | Sees the same rows, from its own side |
| Trail if the MSP is fired | Kept — the record is the client’s, not the MSP’s | Keeps its own copy of the same events |
| Export for an auditor | Exports its own trail without asking the MSP | Exports per client |
| Retention | Set by the platform operator, uniform | Same |
| Legal hold | Requested via the platform operator | Same |
Nine co-management action types are recorded: invitation sent and withdrawn, request sent, link accepted, declined and revoked, primary manager changed, client offboarded, and client gone independent. One row per side, per event.
How it works
- An action happens — someone signs in, an invoice is voided, an MSP’s access is accepted, an integration credential is rotated.
- The service writes an entry before responding, carrying the actor’s id, email and role, the target’s type and id, the caller’s IP and user agent, and the originating service name.
- Secret-bearing fields are stripped from the before/after payload and replaced with
[redacted]— recursively, so a nested credential is caught. - The entry is pinned to a tenant by organization, account, or both. Reads match on the caller’s own keys, so no search or filter can widen the result to another tenant.
- An administrator reviews it at Settings → Audit Log: search by record id, action or actor email, filter by date, and open any row for the full before/after payload, IP and user agent.
- An auditor gets a file — CSV or JSON, server-generated over the whole selected range, with an entry recording who exported it and how much.
- Retention runs only if you configure it, in batches, skipping any tenant under legal hold.
Compliance and audit
What the system produces as evidence, and what it does not.
Recorded on every entry: actor id, actor email as at the time of the action, actor role as at the time of the action, action name, target type, target id, timestamp, originating service, and the tenant keys the entry belongs to. IP address and user agent are recorded on tenant-trail entries.
Recorded on updates: a field-level before/after payload. Fields whose names indicate a secret — password, secret, token, API key, credential, card number, IBAN and similar — are stored as [redacted].
Immutability: no route on any service can update or delete an audit entry. Deleting a user clears the link to their person record but keeps the entry, the actor email and the actor role. Deleting an organization does not remove its entries — the tenant keys carry no foreign key, so there is no cascade.
Retention and hold: entries are kept indefinitely until an operator sets a retention window. A legal hold on an organization or account exempts it from the purge; releasing a hold keeps the hold record, so the fact that a trail was held, by whom and why, remains answerable.
Export accountability: exporting the trail writes an AUDIT_LOG_EXPORTED entry recording the exporter, format, row count, date range, and whether the row cap was reached.
Scope, stated plainly: the unified trail is written by the authentication, asset, billing, integration, platform and AI services. Project, catalog, payment, calendar, notification and email services do not currently write to it. Change management and ticketing keep their own purpose-built histories — complete for their domains, read on their own pages.
Solidlio produces audit evidence intended to support SOC 2, ISO 27001, PIPEDA and GDPR programmes. Tridacom IT Solutions Inc. makes no representation as to the certification status of any Solidlio deployment; certification is assessed against your organization’s controls by your auditor.
Plans and access
Availability depends on your plan, role and account permissions. Capacity limits and service terms apply. Compare current plans and integration requirements, or ask us about your setup.
Ask an MSP for their audit trail and you get a promise; ask Solidlio and you get a file.