Designing an Audit Trail That Survives a SEBI Inspection

Every compliance vendor's pitch deck has a slide about audit trails, and most of them mean "we log things" — a table somewhere with a timestamp and a user ID. That's not what actually survives an inspection. Having built the audit layer under our insider-trading and UPSI compliance products, here's the gap between "we have logs" and "we have an audit trail that holds up when a regulator is in the room asking pointed questions."

The question that breaks most logging setups

A generic application log answers "what happened." An audit trail that survives an inspection has to answer a harder question: "prove to me that this record hasn't been altered since it was created, and prove who saw it." Most systems can answer the first question. Very few can answer the second without a design that was built for it from day one, because "who viewed this" is a category of event application logs simply don't capture — CRUD logging tracks writes, not reads, and in insider-trading compliance, unauthorized reads are the actual risk being regulated against.

Append-only is a design decision, not a database feature

The instinct is to reach for a database feature — a trigger, a change-data-capture stream, a soft-delete flag — and call it done. That covers the mechanics but not the intent. An audit trail that matters treats every table it touches as append-only at the application layer: no record is ever updated or deleted, only superseded by a new row that points back to what it replaced. That distinction matters the moment someone asks "show me exactly what this record looked like on the 14th" — a system built on UPDATE statements can only guess by reconstructing from logs; a system built on append-only rows just returns the row that was active on that date, no reconstruction required.

Access events are first-class data, not incidental logging

The part that's easy to skip is logging reads with the same rigor as writes — who viewed a specific UPSI disclosure, from where, and when. This can't be an afterthought bolted onto a controller method, because that's exactly the layer most likely to get skipped under deadline pressure. It has to sit close enough to the data access layer that viewing a restricted record and logging that view happen in the same transaction, or they'll eventually drift apart — and a gap in access logging is worse than no logging at all, because it looks complete until someone checks.

Immutability has to survive the people who have admin access

The scenario that actually worries a regulator isn't an external breach, it's an internal one — could a system administrator with database access quietly edit a record and cover their tracks? The honest answer for a lot of "audit trail" implementations is yes, because the same account that can write application data can also write the audit table. Closing that gap means the audit layer needs its own write path, ideally with different credentials than routine application access, so that editing a business record and editing the trail of that edit are not achievable through the same compromised login.

Retention is a policy decision before it's a technical one

SEBI's structured digital database requirements come with retention periods, and it's tempting to treat that as a storage-sizing problem. The real design question is upstream of storage: what happens to access logs when an employee who viewed a UPSI record eight years ago has since left the company? The record has to remain queryable and attributable long after the org chart it describes has completely changed, which pushes you toward storing enough context alongside each event — role at the time, not just a user ID that later gets reused or reassigned — that the trail still makes sense read cold, years later, by someone who never worked at the company.

What this actually buys you

None of this is exotic engineering — append-only rows, first-class access logging, a separated write path for the audit layer, and retention that accounts for organizational change over time. What it buys is the difference between handing a regulator a log file and handing them a system that answers their question before they finish asking it. For compliance software specifically, that's not a nice-to-have architecture pattern. It's the actual product.