Audit and Compliance

The problem

The auditor asks a simple question: who granted this contractor access to the finance system, and when. The answer is somewhere in a mailbox, a chat thread, and a ticket that was closed eleven months ago. Your RMM has logs, your accounting package has logs, your identity provider has logs, and none of them share a clock, a user list, or a definition of “user”. If an MSP manages your estate, half the trail sits inside their tenancy and you have to ask them for it — which is exactly the request an auditor will not accept at face value.

What Solidlio does about it

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

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.

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

1. An action happens — someone signs in, an invoice is voided, an MSP’s access is accepted, an integration credential is rotated.
2. 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.
3. Secret-bearing fields are stripped from the before/after payload and replaced with [redacted] — recursively, so a nested credential is caught.
4. 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.
5. 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.
6. 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.
7. 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.

Editions

The audit trail is not plan-gated. Every capability below is present on every tier, including Free — no ServiceTier feature flag governs audit access.

The ITIL change record is the one row with a gate. Reading it requires the BASIC change tier or higher; the hierarchy is false < VIEW_ONLY < BASIC < CAB < ADVANCED, and Free carries false while Starter carries VIEW_ONLY — both below the floor. Growth is BASIC, Scale is CAB, Enterprise is ADVANCED. Change events are still recorded on every tier; the gate is on reading the record through the API.