There is a particular moment in every large compliance exercise when a perfectly reasonable question starts producing increasingly complicated answers. Someone asks whether a regulatory requirement is covered. The answer is immediate: yes, of course. There is a policy for it, a control has been mapped, an owner has been assigned, and the compliance register says the control is active. The meeting moves on. Then somebody asks the question that changes the temperature of the room.
1. “Can you show me how it actually operated?”
Suddenly, the answer requires a little more archaeology. The control owner has one report, Operations has another, Compliance remembers an older process, Technology says the relevant data sits in a different system, and someone eventually suggests checking the shared drive. Ten minutes later, there are four people searching for a file called something like Final_Compliance_Evidence_v3_NEW.xlsx, while everyone quietly hopes that “v3” really was the final version. It is funny because it is familiar. It is also a serious problem.A regulatory requirement does not become an operating control simply because it has been written into a policy or assigned an owner. The organization has to be able to demonstrate that the requirement was translated into a control, that the control actually executed, and that the execution produced evidence capable of showing what happened. Documentation establishes intent. Operational evidence establishes execution.
That distinction is becoming increasingly important for Indian financial institutions, where regulatory expectations increasingly meet complex technology environments, distributed ownership and processes that span multiple systems.Recent RBI enforcement actions illustrate the point from different directions. In August 2026, the RBI imposed a ₹6.20 lakh penalty on Northern Arc Capital after identifying, among other findings, incorrect and incomplete disclosure of customer complaints in its FY2024-25 annual financial statements and failure to ensure auto-escalation of certain partly or wholly rejected complaints to its Internal Ombudsman. Days later, the RBI imposed a ₹2.70 lakh penalty on Progfin for non-compliance with the KYC Directions; the finding included the absence of a system for periodic review of account risk categorisation at least once every six months. Muthoot MCred was separately penalised ₹3.10 lakh for non-compliance with RBI directions on asset classification, with the enforcement action relating to findings from an inspection based on its financial position as of March 31, 2025.
These are not the same regulatory failure, and treating them as though they are would miss the point.
The interesting connection is elsewhere: each shows what happens when a regulatory expectation has to survive contact with the actual operating environment. Because that is where compliance gets difficult.
2. The control exists. The question is whether it happened.
Enterprise compliance has become very good at representing the idea of control. A requirement arrives through a circular, direction or supervisory expectation. Someone interprets it, maps it to a policy, creates a control, assigns an owner and gives it a frequency. The control enters a register. The register appears in a dashboard. The dashboard turns green. Everyone gets a little more comfortable. The problem begins when the conversation moves from “What should happen?” to “What did happen?”. Those questions sound almost identical until you try to answer the second one.Suppose a control requires a particular customer population to undergo a review every six months. The control register can tell you that the requirement exists, who owns it and how frequently it should run. A policy can tell you what the review is supposed to accomplish. A workflow can tell you where the task should appear. None of those things necessarily proves that every customer who should have been reviewed was actually identified, that the review occurred within the required interval, that the resulting classification was recorded correctly, that exceptions were handled, or that someone with appropriate authority reviewed the outcome.
The enterprise can therefore have a perfectly healthy-looking compliance environment while still having a very basic evidentiary problem: it cannot reconstruct the event without asking several people to remember how the process worked. That is the gap between a documented control and an operating control.
3. Welcome to the unofficial compliance archaeology department
Every large organization has one, although it rarely appears on the org chart. Its job begins whenever somebody asks for historical evidence. The first response is usually confident. “It should be in the system.” Then someone checks. It is not there. Or it is there, but only from April onward. Or it is in the old system. Or the old system has been decommissioned. Or the report exists, but it does not contain the population that was actually reviewed. Or the person who used to maintain the report has moved to another team. Or, perhaps most reassuringly of all, someone says, “I have the Excel.” The Excel is then opened. There are twelve tabs. Nobody knows who created tabs eight through twelve. The file is named Final.xlsx, but there is also Final_v2.xlsx, Final_v2_latest.xlsx and Final_v2_latest_updated.xlsx. At this point, the organization has not necessarily failed its control. It has demonstrated something slightly different: its ability to reconstruct the control depends on institutional memory.That is a fragile form of assurance. The more complicated the operating environment becomes, the more dangerous that dependency gets. Regulatory requirements may be interpreted by Compliance, executed by Operations, supported by Technology, monitored by Risk and reviewed by Internal Audit, with each function retaining only part of the evidence. Everyone may be doing their job correctly while the organization as a whole still struggles to produce one connected account of what happened. The problem is therefore not simply missing evidence. It is fragmented evidence.
4. The RBI findings are different. The underlying question is remarkably similar.
- Northern Arc is useful because the finding itself demonstrates why operational traceability matters. The RBI's August 2026 order did not merely concern whether the company had a complaint-handling policy. It identified issues with the information disclosed about complaints and with the escalation of certain rejected complaints to the Internal Ombudsman. In other words, the regulatory requirement had an operational journey: complaints entered a process, decisions were made about them, some required escalation, and the resulting information had to be represented accurately.
- Progfin presents a different kind of problem. The requirement concerned periodic review of customer risk categorization, with the RBI finding that the company did not have a system to conduct that review at least once every six months. Here the interesting question is not whether somebody had written “review customer risk periodically” in a policy. It is whether the organization had an operating mechanism capable of identifying what needed to be reviewed and ensuring that the required cycle actually occurred.
- Muthoot MCred concerns another part of the operating chain altogether. The RBI's action related to asset-classification requirements and findings involving the upgrading of NPA accounts without the required repayment of arrears across credit facilities. Again, the regulatory expectation ultimately meets an operational event: a particular account receives a particular classification based on particular conditions, and the organization must be able to demonstrate that those conditions were satisfied.
5. The five-step journey from a rule to reality
A useful way to think about operational compliance is as a chain:Requirement → Control → Execution → Evidence → ReviewThe first two stages describe the organization's design. The last three describe what happened in reality. That distinction matters because enterprises tend to spend a great deal of effort making the first half of the chain look complete. Requirements are catalogued. Controls are mapped. Owners are assigned. Frequencies are documented. Policies are approved. Dashboards are built. The harder work begins at execution.
A control needs to encounter a real population, transaction, account, complaint, decision or event. Someone or something has to perform the required action. The outcome needs to be captured. Exceptions need to be identified rather than quietly disappearing into an email thread. Evidence needs enough context to establish what happened, when it happened and why the event satisfied the requirement. Finally, someone needs to review the result where the control requires oversight. That creates a very different picture of compliance. The control is no longer simply an entry in a register. It becomes a chain of observable events. And once you start looking at controls that way, the green “Compliant” status begins to look a little lonely without its supporting evidence. A screenshot is evidence. It just isn't always the whole story. The enterprise screenshot deserves some respect. It has probably saved more audit meetings than any other artifact in corporate history.
The problem is that screenshots are very good at proving that something appeared on a screen and considerably less effective at proving the complete history behind that appearance. A screenshot of a reviewed customer record may show a classification. It may not establish why that customer was in scope, when the review became due, whether the entire required population was covered, who performed the review, what changed as a result, whether an exception was raised, or whether somebody subsequently reviewed the exception. The same applies to spreadsheets, emails and exported reports. None of these is inherently bad evidence. They become weak when the organization cannot establish their relationship to the requirement and the control they are supposed to prove.
This is why evidence quality is less about how much material an organization can produce and more about whether the material retains context and lineage. If a regulator asks why a particular action was taken, the organization should not have to assemble a detective team to reconstruct the answer from six systems and seventeen attachments. The evidence should carry enough of the story with it that the organization can move from requirement to control to execution to outcome without relying on memory. Otherwise, the enterprise has something that looks a lot like evidence but behaves a lot like homework.
6. The more dangerous problem is that a control can remain "active" while reality moves underneath it.
Controls do not always fail dramatically. Sometimes nobody deletes the control. Nobody changes its status. Nobody announces that it is broken. The business process simply changes. A workflow moves to another platform. A new system replaces an old one. A responsibility moves from one team to another. A new product changes the population being monitored. An automated rule is modified. An exception that was previously handled automatically now requires manual intervention. A process is redesigned, but the compliance register continues to describe the previous version. Six months later, the control still looks perfectly healthy in the dashboard. Its owner exists. Its frequency exists. Its policy exists. Its status is green. The operating reality underneath it, however, has changed.This is why compliance assurance cannot stop at the existence of a control. The organization has to maintain enough connection between the control definition and the operational evidence to determine whether the control continues to function as intended. That does not mean turning every compliance process into a giant monitoring system. It means preserving the information necessary to answer the simplest question in the room:
Show me.
7. The real compliance test is surprisingly simple.
A useful test for any material regulatory control is to imagine that the regulator does not ask for the policy first. Instead, they choose one requirement and ask the organization to walk them through it from beginning to end. What requirement are you satisfying? Which control addresses it? What triggers the control? What population or event does it apply to? When did it execute? Who performed the action? What was the result? What happened when something did not go according to plan? Who reviewed the outcome? Where is the evidence?If answering those questions requires a succession of calls, forwarded emails and increasingly desperate searches through shared drives, the problem may not be that the organization lacks compliance activity. The problem may be that the compliance activity was never designed to leave behind a connected proof of itself. That is an architectural problem, not merely a documentation problem. And it is becoming more important as organizations digitize more of their operations. The systems executing the business process are increasingly separate from the systems recording the compliance obligation, while evidence is often collected retrospectively for an audit rather than generated as a natural consequence of the control itself.
The result is a strange paradox: organizations can become more automated while becoming more dependent on humans to reconstruct what their automation actually did.
From "Are we compliant?" to "Can we prove it?"The next evolution of compliance is therefore not simply about collecting more policies, adding more controls or creating larger evidence repositories. It is about creating a reliable relationship between the regulatory requirement and the operational event that demonstrates compliance.
Requirement → Control → Execution → Evidence → Review.That chain is deliberately simple. Its value comes from forcing five things that are often separated across the enterprise to remain connected. A requirement should have a defined control. A control should have observable execution. Execution should produce evidence with sufficient context to reconstruct what happened. Evidence should support review rather than merely sit in a folder. And the resulting record should allow the organization to explain its compliance position without depending on whoever happens to remember the process from eighteen months ago. That is what operational assurance looks like.
It is also why the most uncomfortable compliance question is rarely “Do we have a policy?” The more revealing question is: “If someone challenged this control tomorrow, could we prove exactly what happened?” Because there is a big difference between having a compliance system that says Compliant and having a compliance system that can show you why. And if the answer to the second question is, “We should have the evidence somewhere,” it may be time to stop calling that an evidence problem and start calling it what it really is:
A control problem.