Somebody in your company changed a salary field last March. The vendor knows exactly who, and when, and what the number was before. Their system wrote that row at the moment it happened, because an application that updates a record without recording the update is an application that cannot support itself. The row exists on every plan. What varies by plan is whether you are allowed to look at it.
That is the whole of the audit log question, and it is worth being blunt about it, because the usual debate is conducted in the wrong currency.
Storage is not the question
The cost story for gating a log is retention, indexing and export, and none of it is untrue. Keeping years of events costs something. Making them searchable costs something. Building a filtered, paginated, exportable view is real product work, not a line of SQL.
But look at what those costs scale with. They scale with the size of the log, which scales with the number of employees and the amount of activity, which is what a per-seat price already tracks. They do not scale with the plan. A twenty-person company on a free tier writes a small log and reads a small log, and the marginal cost of letting them read it is close to nothing.
So the price on the log is not recovering a cost. It is fencing a tier, and the log is chosen for that job precisely because it appears on enterprise procurement checklists, which is another way of saying it is chosen because the people who ask for it can pay.
The moments you need it are the moments you cannot negotiate
Here is why that particular fence is worse than most.
Nobody browses an audit log. It gets opened in four situations, and all four are bad. A dispute, where an ex-employee says their record was altered and you need to know whether it was. An investigation, internal or otherwise, where somebody saw something they should not have. A diligence request, where an acquirer’s team asks who had access to compensation data and when. A departure that turned hostile, where the question is what was downloaded in the last week and by whom.
The last of those is the one you can stop becoming a search in the first place. Access removal at exit is a checklist item with an owner and a date on it, and when it has been done on the day, the log is confirming what you already know rather than reconstructing what nobody did.
In every one of those, two things are true at once. You need the evidence urgently, and you have no leverage. You cannot spend three weeks evaluating alternatives; you cannot credibly threaten to leave, because leaving takes months and the answer is needed on Thursday. A vendor selling access to the log is selling it to a customer at the exact moment that customer has the least ability to say no. That is not a premium feature, it is a toll booth placed on the one road out of the fire.
And the evidence in question is not the vendor’s. It is a record of what was done to your data, by your people, inside your account. The vendor is the custodian of it. Charging for the reading of it inverts what custody means.
What a genuinely useful log contains
Gating aside, plenty of logs are not worth reading in the first place. Five properties separate a real one from a compliance placeholder.
Who. A person, resolved to a name, not an internal identifier you have to look up. Where the actor was the system rather than a person, that should be visible as exactly that, since a change nobody made is a fact worth knowing.
What and which record. The action and the specific record it touched, so an entry can be traced back to the thing that changed rather than to a screen.
When. A timestamp with a time zone, in a format that sorts.
Old value and new value. This is the property most often missing, and the one that does the work in a dispute. “Salary updated” tells you nothing. “Salary updated from X to Y” is evidence. Absent the before value, the log records that history was rewritten without recording what it said. This is also where a log stops and something else starts: a log tells you that a value changed and when, while effective dating tells you what the record said on a given date, and a diligence question usually wants the second.
Immutability. The entry cannot be edited or deleted afterwards, by anyone, including the vendor’s own staff. A log that an administrator can tidy is not evidence, and it is worse than no log, because it looks like evidence.
Two more things make it usable rather than merely present: filtering by actor, action, record type and date, and an export that leaves your hands as a file somebody else can read. A log you can only page through in a browser is not something you can hand to a lawyer.
How to test a vendor’s log in twenty minutes
Do this in the trial, not after the contract. In a sandbox workspace, perform four actions: change a compensation value, change somebody’s permissions, delete a record, and remove a user’s access entirely.
Then open the log and count how many of the four appear. Deletions are the usual omission, because the record they refer to is gone and the log was built by joining to it. Check whether the compensation entry carries the old value. Check whether the permission change names both the old role and the new one. Then export the result and open the file yourself.
Then ask three questions in writing. How long are entries retained, in months. Can anybody, including your staff, edit or remove an entry. And what happens to the log when the subscription ends or lapses, since a log you lose at the moment of departure is unavailable in precisely the scenario that made you ask for it. The security questionnaire guide puts these alongside the other categories a reviewer works through, and they are the same questions whether you are answering or asking.
Where we stand
Every Capstan workspace gets its own activity log, on every plan, including the free one. A workspace administrator opens it inside the product, filters by action, record type or date, pages through it and exports it. Actor identifiers resolve to a person’s name, and a change made by the system rather than a person shows as that.
It is append-only in the database itself rather than by convention: update and delete are revoked on the table, and a trigger rejects any mutation that gets past that, so an entry cannot be quietly edited afterwards by anyone, us included. The read endpoint checks for a workspace administrator on its own rather than leaning on a broader policy, and rows stay scoped to your workspace whoever is asking. The mechanisms are set out on the security page with what proves each one.
The reason it is not sold is not generosity. A plan here differs from another plan in exactly two ways, how many active employees it may carry and whether it may enable a paid module, and both are enforced in the database rather than in the interface. The whole core is on every plan, free up to twenty people, and the pricing page publishes what the paid parts cost. An audit trail you have to buy is not an audit trail, it is a receipt for one.