What Audit Trails Actually Require of Your Software

For: A Series A fintech or B2B SaaS founder in India who has just received a due-diligence questionnaire from an enterprise customer or RBI-regulated partner asking for 'audit trails and record-keeping evidence' — and realised their logging is ad hoc, lives in application logs, and will not survive a serious audit

If an enterprise customer or an RBI-regulated partner has asked for your audit trails, they are not asking for your application logs. They are asking whether your system can produce a tamper-evident, retention-controlled, on-demand record of who did what, when, and to which entity — and whether that record is stored somewhere your own engineers cannot silently rewrite. Most Series A fintechs in India fail this review not because they have no logs, but because their logs live in the same Postgres instance the app writes to, are deletable by the same admin role that runs production, and have no retention policy tied to a named regulation. That is the gap this post is about.

The regulations you are up against are not vague. India's Ministry of Corporate Affairs made audit trails mandatory for every company using accounting software from April 1, 2023, and the associated records must be preserved for eight years under Section 128(5) of the Companies Act (India Briefing). The RBI's Master Direction on IT Governance, Risk, Controls and Assurance Practices (ITGRCA), effective April 1, 2024, is binding on banks, NBFCs, HFCs, and payment system operators, and it is explicit about what audit trails must do (RBI ITGRCA 2023). SEBI has its own system audit framework for brokers and clearing members with penalty structures for failures (SEBI Master Circular, October 2023). If you sell to any of these constituencies — or to an enterprise that does — this applies to you by contract even if not directly by regulation.

What actually triggers the obligation

Four separate things can put you on the hook, and founders routinely conflate them.

The Companies Act trigger. If you are an Indian company using accounting software — and every fintech is, if only for its own books — you are already obligated. The MCA rule applies to OPCs, small companies, dormant companies, and foreign companies with Indian operations. There is no threshold. The audit trail must record every transaction in the accounting system, cannot be disabled, and must be preserved eight years.

The RBI trigger. If you are an RE (Regulated Entity) — bank, NBFC, HFC, payment aggregator, PPI issuer, payment system operator — the ITGRCA directions apply directly. If you are a SaaS vendor selling to an RE, they apply through your customer's outsourcing and IT-risk obligations, which is why the DDQ landed on your desk.

The SEBI trigger. Stock brokers, clearing members, depositories, and their tech vendors fall under SEBI's system audit framework — mandatory audits, reports filed to the exchange, and closure of non-compliance observations on the clock.

The IT Act trigger. Section 7A of the IT Act makes audit provisions apply equally to electronic records — so any obligation to have books auditable applies to your database the same way it applies to a paper ledger (IT Act, 2000).

The practical version: if your customer is regulated, you inherit the shape of their obligations through the contract. The DDQ is the mechanism.

What the architecture actually has to do

This is where the policy binder stops being useful. A control that exists only on paper — 'we log all user actions' — fails an auditor the moment they ask show me the log for user ID 88213 changing the KYC status on loan application 45012 on the 14th of last month, and prove to me it hasn't been altered since. Six things have to be true of your system for that question to have a clean answer.

1. Logs must be immutable relative to the application

The RBI directions require audit trails to be 'secured to ensure the integrity of the information captured and preservation of evidence' and to be usable as forensic evidence and for non-repudiation (RBI ITGRCA). In plain terms: the credentials that run your application cannot be the credentials that can delete or modify the log. A Postgres audit_events table owned by the same user your API writes with does not clear this bar. Common patterns that do:

• Append-only log storage (S3 with Object Lock in Governance or Compliance mode, or equivalent WORM storage on Azure/GCP)
• Separate database with a distinct credential path — writeable only by a signing service, readable by auditors, deletable by no one on the application team
• Hash-chained records where each log entry contains a cryptographic hash of the previous one, so any tampering breaks the chain
• Third-party log sinks (a SIEM, a managed log store) with segregated IAM

Any system that permits record modification without a corresponding audit entry is explicitly non-compliant under the RBI framework (Writer Information on BFSI compliance).

2. Logs must live outside the application database

The ITGRCA directions require REs to 'put in place effective log management and retention framework comprised of tools to manage, collect and store system and application logs.' The phrasing matters. A framework implies a separate system. If a database restore also restores the audit trail — and both are performed by the same DBA — you do not have an audit trail. You have a diary.

The practical minimum here is log shipping. Application writes an event; a shipper (Fluent Bit, Vector, or the cloud provider's native agent) forwards it to a separate destination with different access controls. Ideally the shipper signs each event or the destination applies immutability on write.

3. Every event must carry the five Ws

Auditors will ask for a specific reconstruction. The event schema needs, at minimum:

• Who — authenticated user ID, not just a session ID; for service-to-service calls, the service identity
• What — the action taken, expressed at the business level ("loan.status.changed") not just the HTTP verb
• When — server-side timestamp with timezone, ideally from a trusted time source, not the client clock
• Which entity — the primary key of the record affected, and enough context to identify it (loan ID, customer ID, transaction reference)
• Before/after values — for state changes, both the old value and the new value; this is where most homegrown systems fail
• From where — source IP, device fingerprint, request ID, correlation ID that ties this event to the broader user session

Reads matter too, not just writes. If someone queries a customer's Aadhaar-linked KYC record, that read is an event under most fintech DDQs even though it changed nothing.

4. Retention has to be tied to a named rule, not a default

Eight years under Section 128(5) of the Companies Act for accounting records. RBI expects retention periods to be defined, documented, and enforceable. Ten years is a common conservative choice for regulated financial data in India, though the actual number depends on which regulations apply and a lawyer should confirm what fits your specific business.

The architecture question is: does your log store enforce the retention, or is it just written into the runbook? Object Lock with a retention period set at write time enforces it. A cron job that deletes old logs is enforcement in reverse and will not pass.

5. Reads have to be possible without engineering involvement

This one surprises founders. If your only way to answer "show me every action on loan 45012" is to have an engineer write a SQL query, that is not a control — that is a favour. Auditors and enterprise security teams want to see either a self-service audit console (role-restricted, read-only, with its own audit trail of who searched what) or a documented request procedure with an SLA. Homegrown Metabase dashboards over a raw log table usually do not clear this bar because they run with credentials that could also mutate the data.

6. The trail itself has to be audited

Access to audit logs is itself a logged event. Who read the trail, when, for what reason. Yes, it is recursive. Yes, it is required.

What this demands of the vendor you hire

If you are outsourcing the build, or evaluating an off-the-shelf audit-logging product, the checks that matter more than the sales deck:

• Where the logs physically sit. India data residency is not optional for many RBI use cases. If the vendor's log store is a US-region S3 bucket, you have a problem.
• Whether the vendor can access your logs. A managed logging SaaS with plaintext access to your customer PII is a separate compliance problem. Look for customer-managed keys and encryption-at-rest with keys you control.
• Whether the schema is yours or theirs. A proprietary event schema you cannot export cleanly is a lock-in problem the moment an auditor wants raw evidence.
• Whether the vendor has been through an audit before. Ask specifically for a redacted evidence pack from a prior RBI IS audit or SEBI system audit involving their product.
• IP and code ownership if the vendor is a services firm building this for you. Audit-trail plumbing sits at the core of your system; you do not want to license it back from your builder.

How long readiness takes, and what drives the number

There is no honest single answer here — the range is wide because it depends on where your system is today. What actually drives the timeline:

• How much of your data model is event-sourced vs. state-mutating. An app that already emits domain events for every state change is weeks away from a compliant trail. An app that does UPDATE users SET kyc_status = 'verified' WHERE id = ? without emitting an event is months away, because every write path has to be instrumented.
• Number of services in scope. A monolith is faster to instrument than fourteen microservices with inconsistent logging conventions.
• Whether you need historical backfill. If the auditor wants trails going back to when the product launched, and you have no source-of-truth for those events, this is a data reconstruction project on top of a logging project.
• Whether the customer DDQ requires a specific certification (SOC 2 Type II, ISO 27001) versus just evidence of controls. Certification adds months of observation-period time regardless of how fast the engineering is done.

Illustrative shape only: a Series A fintech with a single-service Node/Postgres backend, roughly forty write endpoints, no existing event bus, targeting an RBI-vendor DDQ (not a fresh certification) is typically looking at a multi-month engineering effort to reach a defensible trail — instrumentation, log shipping to an immutable store, retention policy, and a basic audit console. Add materially more time if certification is in scope, if data residency requires cloud migration, or if backfill is demanded. To turn this shape into a real quote, you need three things scoped: (1) which regulation is actually being asserted against you, (2) how many write paths and services need instrumentation, and (3) whether historical events must be reconstructed. A conversation with an engineering team like CodeNicely — one that has built compliance-adjacent fintech systems — is where that scoping happens.

The three things teams discover far too late

One: your reads are also regulated. Every founder instruments writes first and assumes reads are free. In fintech they are not. Access to KYC data, credit scores, transaction history — those reads are events, and if you cannot show who read what, DDQs go sideways in the second round of questions.

Two: your admin panel is the biggest hole. Support engineers with 'god mode' who can override a stuck KYC or refund a transaction are the highest-risk actors in the system and the least logged. Auditors know this and go straight there. If your Retool or Forest Admin instance writes directly to Postgres with a shared credential, you are effectively logging nothing.

Three: log volume becomes a cost line. A properly instrumented fintech at meaningful transaction volume produces log volumes that surprise the finance team. Retention for eight or ten years compounds this. Founders who ignored storage tiering find themselves rearchitecting the log pipeline eighteen months in. Plan for cold storage tiers (S3 Glacier Instant Retrieval, or equivalent) from day one.

How CodeNicely can help

The engagement that most resembles this situation is GimBooks, a YC-backed accounting and invoicing SaaS for Indian SMBs. That product operates directly in the surface area of the MCA audit-trail mandate — every invoice, ledger entry, and GST-relevant transaction has to carry a trail their customers can produce to their auditors. Building for that constraint meant designing the event and retention model into the data layer, not bolting it on later, and it meant treating admin actions with the same rigour as customer actions.

If you are staring at a DDQ and your logs are ad hoc, the useful conversation is not about tools — it is about which regulation is actually being asserted against you, what your write and read surface looks like today, and what the shortest defensible path is to a trail an auditor will accept. Our engineering studio works with fintechs at exactly this stage, and you keep full IP ownership of the compliance plumbing we build, which matters when the next auditor after this one asks the same questions.

Frequently Asked Questions

Do audit trail requirements apply to my startup if I am not directly regulated by RBI or SEBI?

Yes, in two ways. The MCA's Companies Act mandate applies to every Indian company using accounting software, with no size threshold, since April 1, 2023 (India Briefing). And if you sell to a regulated customer, their outsourcing obligations flow to you by contract, which is why enterprise DDQs ask for the same evidence a regulator would.

Are application logs in a database table sufficient for an RBI IS audit?

No. The RBI ITGRCA directions require an effective log management and retention framework with integrity guarantees and forensic usability. Logs stored in the same database the application mutates — deletable or editable with the same credentials that run production — do not satisfy the integrity requirement and are typically flagged during an IS audit.

How long do I have to retain audit trails in India?

Section 128(5) of the Companies Act requires books of account and the associated audit trail to be preserved for at least eight years. Sector-specific rules under RBI, SEBI, and IRDAI can impose longer or additional retention periods depending on the record type. A lawyer or auditor familiar with your specific regulatory footprint should confirm the exact retention matrix that applies to your business.

What does it cost to make a system audit-trail compliant?

The cost is driven by three variables: how many write paths and services need instrumentation, whether logs can be shipped to immutable storage in the current cloud setup or require infrastructure changes, and whether historical backfill is in scope. Certification (SOC 2 Type II, ISO 27001) adds cost independent of the engineering because of the observation period and external auditor fees. To turn a range into a real number, the scope has to be pinned down in a conversation — which specific regulation, which services, and which evidence artifacts the DDQ actually demands.

Is a SIEM enough to satisfy audit trail requirements?

A SIEM helps with the storage-and-access side but does not solve the instrumentation side. If your application does not emit business-level events with before/after values, correlation IDs, and authenticated user identity, no downstream SIEM can reconstruct what the auditor is asking for. The SIEM is the destination; the instrumentation inside your application is the harder half of the problem.