When a startup tells us "we already have audit logs," we ask them to forward the most recent procurement questionnaire they've answered. Nine times out of ten, the answers reveal a product that has the right idea but won't survive a serious review. Below is the list of items that show up in those questionnaires — written from the buyer's side, so you can grade your own implementation against it.
1. Tamper-proof storage
The first question on every SOC 2 and HIPAA questionnaire. A CREATE TABLE events with an admin who can run DELETE against it is not tamper-proof. Buyers want one of three things: append-only storage at the infrastructure layer, cryptographic chaining so any modification is detectable, or both. They also want to know who has the credentials to bypass it. "Only a few people on the platform team" is a perfectly acceptable answer — "we don't really restrict it" is not.
2. Configurable retention per environment
Compliance frameworks specify retention windows. SOC 2 doesn't mandate a single number, but auditors want to see that you've decided on one and that it's enforced automatically. HIPAA requires six years for healthcare. Some financial use cases require seven. The system should let the customer set the policy and prove that older events are archived or deleted on schedule, with documentation.
A flat retention setting that applies globally is a yellow flag. Buyers running multiple environments (staging, production, regional segregations) want to set retention per environment and get reports per environment.
3. Schema consistency
This is the quiet killer. A team builds an audit log over time, with each feature adding events in whatever shape made sense that week. By the time the SOC 2 audit lands, half the events have an actorId field, half have userId, and a few have neither. The auditor asks for "all admin actions in the last 30 days" and you can't answer because the schema isn't queryable.
Every event needs the same five fields, even when the values are empty: who did it, what they did, what they did it on, when, and the result. Custom metadata is fine — putting a feature's specific context inside a structured metadata field is exactly the right move. Putting that context into top-level fields that vary post-by-post is what creates the schema drift.
4. SIEM export
Enterprise security teams have an existing investment — usually Splunk, Datadog, or an in-house platform fed from S3. They are not going to add your dashboard to their oncall rotation. They want events streamed to where their alerting already lives.
"You can export a CSV" is not the answer they're looking for. Streaming integration with the major SIEM platforms, with retry on failure and a way to backfill if the destination is down, is what gets a check mark.
5. Searchable, filterable history
Investigations under time pressure are the use case. A breach notification clock is ticking, oncall is trying to find every action a compromised account took in the last 72 hours, and the answer cannot be "let me write a SQL query." Full-text search across event metadata, filters by actor and action and target and time range, and pagination that handles a million matches without choking — those are table stakes.
6. End-user visibility
The customer's customers — the actual end-users — increasingly expect to see their own activity. Login attempts, settings changes, sessions revoked, devices added. This is the easiest checklist item to ignore in early product, and the one that quietly costs deals once a buyer's security team starts asking about it. An embeddable activity log that customers can drop into their own product surface, themed to match, removes this from the engineering backlog without making it the security team's problem.
7. Independently verifiable integrity
The most rigorous buyers — financial services, healthcare, anyone with a regulatory body breathing down their neck — want to verify the audit log themselves, without relying on the vendor's word. A cryptographic chain that any party can recompute from the ground up, plus an endpoint that returns the proof, satisfies this. Most products don't do it. The ones that do tend to win the regulated deals.
How to grade yourself
If your audit log fails three or more of these, expect procurement reviews to take longer than the engineering work to fix it. If it fails one or two, you'll probably get through but with a remediation item attached to the contract. If it passes all seven, you've built something that won't be the reason the deal slips — which is the only reasonable goal for an audit log to have.