The Scenario
Sunita is the compliance head of a mid-sized non-banking financial company (NBFC) in Mumbai. Her organisation had deployed an RPA solution to automate the KYC onboarding process — the bot collected applicant documents, cross-referenced identity data against government databases, triggered verification workflows, and updated the CRM with onboarding status. At its peak, the bot processed over eight hundred KYC applications per day.
The bot operated using a shared service account with administrative-level access to the customer data platform, the CRM, and the document management system. The credentials for this service account were stored in plain text in a configuration file on the deployment server — a common but critically insecure practice that IS Audit 3.0 had flagged as a known RPA risk.
In March 2025, an external attacker gained access to the deployment server, retrieved the bot’s credentials, and used them to access the customer data platform. Over three days, approximately 14,000 customer records — including names, Aadhaar numbers, PAN cards, income data, and bank account details — were exfiltrated. Because the bot routinely accessed the same systems under the same credentials, the access logs did not initially flag the intrusion as anomalous.
Sunita’s team discovered the breach only when a customer reported a fraudulent loan application made in her name.
The DPDP Act Position
The NBFC’s RPA deployment created four overlapping compliance failures — each of which independently triggered DPDP Act liability.
First — Rule 6(1)(a) security safeguard failure: absence of encryption or credential protection. Rule 6(1)(a) requires the Data Fiduciary to protect personal data through encryption, obfuscation, masking, or the use of virtual tokens. Storing bot credentials in plain text in a configuration file is the antithesis of this requirement. These credentials provided direct, unrestricted access to over 14,000 customer records containing sensitive personal data. The absence of any credential protection is a straightforward violation of the minimum security standard.
Second — Rule 6(1)(b) failure: inadequate access control. Rule 6(1)(b) requires appropriate measures to control access to computer resources. A shared service account with administrative-level access to multiple systems is structurally non-compliant. Principle of least privilege — a foundational security and governance concept — requires that the bot be granted only the minimum access necessary to complete its specific task. Administrative access across the customer data platform, CRM, and document management system simultaneously is access far in excess of what any individual process requires.
Third — Rule 6(1)(c) failure: inadequate monitoring and log review. Rule 6(1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring, and review to enable detection of unauthorised access. The breach went undetected for three days because the attacker’s access was indistinguishable from the bot’s normal access pattern. This means the NBFC had no mechanism to detect anomalous access against the baseline of expected bot behaviour — a direct failure of the monitoring obligation.
Fourth — Section 8(6) and Rule 7 breach notification failure. The NBFC discovered the breach only through a customer report. Had detection systems been in place, earlier identification would have been possible. Upon discovery, Rule 7 required immediate notification to affected Data Principals and notification to the Data Protection Board of India within seventy-two hours — including the nature and extent of the breach, its likely consequences, measures being taken to mitigate risk, and remedial steps to prevent recurrence. The delay caused by inadequate monitoring made timely compliance with these obligations impossible.
The penalty exposure under the Schedule to the DPDP Act is substantial. A breach of the obligation to take reasonable security safeguards under Section 8(5) attracts a penalty of up to ₹250 crore. A failure to notify under Section 8(6) attracts up to ₹200 crore. These are not theoretical upper limits — they are the statutory framework within which the Data Protection Board will exercise its discretion.
The IS Audit 3.0 Perspective
The study material on IS Audit 3.0 by ICAI identifies tool selection risk and operational execution risk as primary RPA governance failures. Specifically, it notes that when bots are deployed without a proper operating model, roles and responsibilities become blurred in production. In Sunita’s case, the operating model had no provision for credential management, access scoping, or anomaly detection — a governance gap that directly enabled the breach.
IS Audit 3.0 requires that RPA governance frameworks specifically address operational risk and data security through cross-functional team involvement, including legal and risk functions. Had this standard been applied, credential storage protocols, access control scoping, and monitoring requirements would have been part of the deployment framework — not afterthoughts discovered in a breach investigation.
Furthermore, IS Audit 3.0 notes that auditors engaging with RPA-enabled organisations must focus on control design opportunities and develop new testing approaches for bot-driven processes. Specifically in the DPDP compliance context, this means IS auditors should treat each RPA bot as a data processing entity and audit its access rights, credential management, output routing, and log review protocols as rigorously as they would audit any human-operated system.
The Compliance Fix
Any NBFC, financial institution, or organisation deploying RPA for processes involving sensitive personal data must urgently address:
→ Credential security: bot service account credentials must be stored in an encrypted secrets management vault — never in plain text in configuration files. This is the minimum standard under Rule 6(1)(a).
→ Access scoping: every bot must be assigned a service account with the minimum permissions necessary for its specific task. Administrative-level, cross-system access for a single bot is never appropriate when individual process-scoped access is achievable.
→ Anomaly detection baselines: organisations must establish normal bot behaviour profiles — typical access volumes, access times, data retrieval patterns — and configure monitoring alerts that fire when actual behaviour deviates from these baselines. Rule 6(1)(c) requires this level of visibility.
→ Breach response rehearsal: RPA-related breaches are difficult to detect quickly because bot access is indistinguishable from normal operations without baseline monitoring. Organisations must rehearse their breach detection, escalation, and notification workflows specifically for bot-related incidents — so that the Rule 7 seventy-two-hour notification obligation can be met when it matters.
→ IS Audit 3.0-aligned annual review: every RPA deployment processing personal data must be audited annually using IS Audit 3.0 standards, with specific attention to credential management, access control design, and log review sufficiency.
Sunita’s NBFC had an efficient KYC bot. However, it had no compliant security architecture around it. Fourteen thousand customers paid the price for that gap.
The Central Compliance Question for RPA Deployments
The unique DPDP compliance challenge that RPA creates is one of invisibility. Unlike a human employee who processes personal data visibly and accountably, an RPA bot processes data silently, continuously, and often without any mechanism for the organisation to know precisely what it touched, where it sent it, and what secondary data stores it created in the process.
The DPDP Act, however, applies equally to automated and human processing. Section 2(x) defines processing to include every operation performed on digital personal data — and Section 2(b) defines automated as any digital process capable of operating automatically. Together, these definitions mean that an RPA bot is not operating outside the Act’s scope. It is operating at the centre of it.
Every organisation deploying RPA on personal data must therefore answer five questions — not once at deployment, but continuously throughout the bot’s operational lifecycle:
One. Have we mapped the complete data footprint of every RPA process — including every system accessed, every intermediate file created, every output generated, and every downstream system that receives data?
Two. Does every bot service account operate on the principle of least privilege — with access strictly scoped to the minimum data necessary for the specific task it performs?
Three. Are bot credentials stored securely — encrypted in a secrets management system, rotated regularly, and audited for access?
Four. Do we have anomaly detection baselines for each bot’s data access behaviour, with alerts configured to flag deviations for human review?
Five. Can we honour a Data Principal’s Section 12(3) erasure request across the full data footprint of a bot process — including staging environments, output files, and communication logs?
IS Audit 3.0 states that a governance structure defining roles and responsibilities for automation activities is essential for successful RPA initiatives. Under the DPDP Act, that governance structure is not a success factor — it is a legal obligation.
What Responsible RPA and DPDP Compliance Looks Like
IS Audit 3.0 correctly observes that RPA is not replacing accountants but augmenting their effectiveness — creating space for professionals to focus on higher-value analytical and advisory work. That observation is true, and the productivity benefits of well-governed RPA are real. However, realising those benefits without simultaneously creating DPDP compliance liability requires a deliberate, structured approach to bot governance.
Responsible RPA and DPDP compliance means treating every bot as a named, scoped, audited data processor. It means mapping every process before deployment, monitoring every execution in production, and maintaining the ability to respond to any Data Principal rights request across every processing environment the bot touches.
The organisations that achieve this are not those with the most bots. They are those with the best governance around each one. Automation scales efficiency — but without proper controls, it also scales compliance risk at exactly the same rate.
The DPDP Act has made that tradeoff unambiguous. Organisations now need to make a deliberate choice. The compliance deadline is 13 May 2027.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.