Compliance Automation: India GC Case Study

The Starting Point: A Compliance Function Held Together by Spreadsheets

Before the programme began, the company's entire compliance calendar lived in a shared spreadsheet maintained by the company secretary and two junior colleagues. It listed obligations, owners, and due dates across roughly forty categories, colour-coded by status. On paper it looked organised. In practice it was carrying more risk than anyone had admitted out loud. The spreadsheet had no memory: when a filing was completed, someone changed a cell, but there was no evidence of who filed what, when, or with which acknowledgement number. When a director asked during a board meeting whether all statutory registers were current, the honest answer was that the team believed so but could not prove it in the room.

The deeper problem was that the calendar depended entirely on the people who maintained it. Knowledge of why a particular RBI return was due, or which factory licence renewed in which month, sat in the heads of two individuals. When one of them was on leave during a quarter-end, a半 GST reconciliation slipped and was caught only because an alert accountant noticed the mismatch. The near-miss was the trigger. The general counsel commissioned a review, and the review reached an uncomfortable conclusion: the company was not non-compliant, but it was one resignation or one illness away from being unable to demonstrate compliance at all.

That distinction, between being compliant and being able to prove it, became the organising idea of the whole programme. Regulators, auditors, and boards increasingly demand the second, not merely the first. A spreadsheet, however diligently kept, cannot produce a defensible evidentiary record of an obligation met on a date with an attached acknowledgement. That is what the team set out to build.

• A single shared spreadsheet tracked roughly forty compliance categories across four states
• No durable record existed of who filed what, when, or with which acknowledgement number
• Critical knowledge of obligations lived in two individuals, creating key-person risk
• A quarter-end GST reconciliation nearly slipped during a period of staff leave
• The real gap was evidentiary: the team could not prove compliance, only assert it

Why a Compliance Automation Case Study Matters More Than a Feature Demo

It is worth pausing on why this compliance automation case study is framed as a narrative rather than a product tour. Legal teams evaluating automation are shown polished dashboards constantly, and the dashboards all look competent. What the demos rarely reveal is the unglamorous work that determines whether the software succeeds: cleaning the obligation register, deciding who truly owns each task, and rebuilding trust after a near-miss. The value of a case study is that it exposes that work honestly, so a general counsel can estimate not just the destination but the road.

The India dimension makes this especially important. The Indian compliance environment is unusually fragmented across central regulators, state authorities, and sector-specific bodies, and obligations change frequently through circulars, amendments, and notifications rather than through neat annual rewrites. An automation approach that works in a single-regulator jurisdiction can be naive here. This team learned that the platform mattered less than the operating model wrapped around it, and that the operating model had to account for the reality that a SEBI circular or a state labour notification could change an obligation with a few weeks' notice.

• Product demos hide the unglamorous data-cleaning work that determines success or failure
• India's compliance surface spans central regulators, state authorities and sector bodies at once
• Obligations here change through circulars and notifications, not tidy annual rewrites
• The operating model around the tool matters more than the tool's feature list

Phase One: Building a Trustworthy Obligation Register

The team resisted the temptation to buy software first. Instead they spent the first ten weeks rebuilding the obligation register from primary sources rather than copying the old spreadsheet, because copying a flawed list into a new system only makes the flaws harder to see. For each obligation they recorded the governing instrument, the triggering event, the frequency, the responsible role rather than the responsible person, the evidence required to close it, and the consequence of default. This last field changed behaviour: seeing that a lapsed obligation carried a monetary penalty or a director-level consequence made owners take assignment seriously.

This phase surfaced obligations no one had been tracking. A data-processing activity that had quietly begun two years earlier now fell squarely within the expectations of the Digital Personal Data Protection Act 2023, which introduces consent, purpose-limitation, and breach-notification duties that the company had not formally mapped. A subsidiary's factory licence was found to be renewing on a cycle nobody owned. The register grew from forty categories to over ninety discrete obligations, which was not scope creep but the visibility the old system had been hiding.

Phase Two: Automating the Calendar, the Alerts, and the Evidence

Only once the register was trustworthy did the team automate. The platform they adopted turned each obligation into a scheduled, owned task with escalating reminders, and critically required an evidence artefact to close a task rather than a status change. Closing a GST filing now meant attaching the acknowledgement; closing a board obligation meant linking the signed minutes. The system built the audit trail as a by-product of ordinary work, which is exactly what the old spreadsheet could never do.

The alerting logic was tuned carefully, because the fastest way to kill a compliance system is alert fatigue. Reminders escalated on a schedule keyed to the consequence of default: a high-penalty SEBI disclosure escalated to the general counsel days before deadline, while a low-risk internal renewal simply reminded its owner. A regulatory-change feed flagged when a relevant circular or amendment was issued, prompting a human to assess whether an obligation needed updating, because the team wisely refused to let the software decide legal questions on its own.

The second reversed decision happened here. The team initially tried to automate the interpretation of regulatory changes, hoping the system would update obligations when a notification appeared. It produced noise and false confidence, and they pulled it back to a human-in-the-loop model: the software surfaces the change and drafts a suggested impact, a qualified person decides. That posture, automation for detection and routing, human judgment for legal conclusions, became a governing principle.

• Each obligation became a scheduled, owned task with escalation keyed to default consequence
• Closing a task required an evidence artefact, building the audit trail automatically
• Alert escalation was tuned by risk to avoid the fatigue that kills compliance systems
• A regulatory-change feed flagged relevant circulars for human assessment, not auto-update
• Interpretation of legal changes stayed with qualified people, not the software

The DPDP Act 2023: The New Obligation That Justified the Whole Programme

If the SEBI and Companies Act obligations were the familiar backbone of the programme, the Digital Personal Data Protection Act 2023 was the obligation that made senior management pay for it. Unlike the mature disclosure regimes the team had managed for years, data protection was new, cross-functional, and touched systems the legal team did not control: HR databases, marketing tools, customer records, and vendor arrangements. Mapping these data flows was impossible in a spreadsheet and became one of the automation programme's clearest wins.

The team used the register to catalogue every processing activity, its purpose, its lawful basis, the consent position, and the retention rule, then tied breach-notification readiness to a defined workflow so that a suspected incident would trigger assessment and, where required, notification within the expected timelines rather than being handled ad hoc. Because the DPDP framework is being operationalised through rules and phased enforcement, the team deliberately built the workflow to be adjustable, treating the obligation as a living one rather than a fixed checklist. This is precisely the kind of evolving, multi-system obligation that spreadsheet tracking handles worst and structured automation handles best.

• DPDP duties were cross-functional and touched systems outside legal's direct control
• The register catalogued each processing activity, purpose, lawful basis, consent and retention
• Breach-notification readiness became a defined, triggerable workflow rather than ad hoc
• The workflow was built to flex as DPDP rules and enforcement are phased in

The Outcomes: From Monthly Scramble to Managed Process

Eighteen months in, the change was visible in ways the board could feel. The monthly compliance scramble that had consumed the last week of every quarter became a routine review of a live dashboard. When a director asked whether all statutory registers were current, the company secretary could answer in the room, with the evidence attached. An internal audit that would previously have meant weeks of assembling proof became an export. The figures below are representative of what mature deployments of this kind report; they are ranges, not guarantees, and the actual return depends heavily on the quality of the register underneath.

Just as important as the metrics was the cultural shift. Compliance stopped being the anxiety of two individuals and became a shared, visible process with clear ownership. The near-miss that started everything could no longer happen the same way, because no single person's absence could hide the state of an obligation. That resilience, more than any single efficiency, was what convinced the general counsel the investment had paid for itself.

What This Case Study Teaches Teams Considering Automation

The transferable lessons from this programme are less about technology than about sequence and discipline. The single most important decision was refusing to automate until the obligation register was trustworthy, because automation amplifies whatever it is given, clean data or confusion alike. The second was the human-in-the-loop posture on legal interpretation, which protected the team from the false confidence that undoes many compliance tools. The third was designing alerts around consequence rather than treating every obligation as equally urgent, which kept the system credible instead of ignorable.

There are also honest cautions. This kind of programme demands sustained senior sponsorship, because the unglamorous register-building phase produces no visible output for weeks and is easy to abandon. It requires accepting that the tool will surface uncomfortable gaps, which is the point, not a failure. And it requires treating Indian regulatory change as continuous, building the process to absorb circulars and amendments rather than assuming an annual refresh. Teams that internalise these lessons tend to succeed regardless of which specific platform they choose; teams that buy software hoping it will supply the discipline they lack tend to be disappointed.

• Clean the obligation register before automating; software amplifies confusion as readily as order
• Keep legal interpretation with qualified humans and use automation for detection and routing
• Design alert escalation around the consequence of default, not uniform urgency
• Secure senior sponsorship to survive the invisible register-building phase
• Build the process to absorb continuous Indian regulatory change, not an annual refresh