India's Digital Personal Data Protection (DPDP) Act asks data fiduciaries to put in place reasonable security safeguards to protect personal data they hold or process. Centralizing staff authentication through SSO is one small, visible contributor to a firm's broader access-governance posture — it's evidence the firm has thought about who can reach its systems and how — but it is not, by itself, a compliance measure, and nothing here should be read as legal advice about what the DPDP Act specifically requires of any individual firm.
Where a CA firm sits under the DPDP Act
A CA firm handling client financial data, employee records, and other personal information is likely to be acting as a data fiduciary (or in some arrangements, a data processor) in relation to at least some of that data. What specific obligations attach, and how they apply to a given firm's particular data flows, depends on facts a firm should work through with its own legal counsel — this article isn't attempting to settle that question, only to place SSO correctly within the larger picture once a firm has decided it has obligations to meet.
This is deliberately not legal advice. The DPDP Act's rules, exemptions, and enforcement mechanics are still maturing, and how they apply to a specific firm's data handling is a question for that firm's own counsel, not a marketing page about a login feature.
What SSO contributes to an access-governance story
- A single point where the firm can enforce its own password strength and session policy, rather than that policy varying tool by tool.
- A faster, more reliable offboarding path — access to a connected tool is cut the moment the firm disables someone at its identity provider, rather than depending on someone remembering a separate step.
- A cleaner audit trail of who authenticated when, centralized at the identity provider rather than scattered across each tool's own login logs.
- One fewer password for staff to manage badly — reused passwords and weak passwords are a real, common failure mode that SSO removes from the picture for connected tools.
What SSO does not demonstrate
None of the above is the same as having a complete security safeguard program. A 'reasonable security safeguards' standard, however it ends up being interpreted, is about the whole system: how data is stored, who can access what and why, how breaches are detected and reported, how long data is retained, and how access is reviewed over time — not about any single login mechanism. A firm that has SSO switched on but no process for reviewing who has access to what, no retention discipline, and no incident-response plan has not addressed its obligations by turning on SSO.
Treating 'we have SSO' as an answer to a client's or regulator's question about data protection overstates what the feature does. SSO changes how someone proves their identity on login. It says nothing about encryption, retention, breach response, or whether the right people have access to the right client files — all separate questions a firm's broader access-governance and data-protection practice has to answer on its own.
The honest framing
| Access-governance question | Does SSO address it? |
|---|---|
| Can the firm quickly cut off a departed employee's access? | Yes, for connected tools — this is SSO's main contribution |
| Is the firm's password policy consistently enforced? | Partly — centralizes policy enforcement at the identity provider |
| Does the right staff member have access to the right client's files? | No — that's role and membership management, separate from SSO |
| Is the firm handling personal data in line with DPDP Act obligations generally? | No — SSO is one small input to a much larger governance and legal question |
How we think about this
Lekhya treats SSO as exactly what it is: a Firm-plan authentication feature that centralizes login against a firm's own OIDC identity provider. It's a genuine, useful contributor to a firm's access-governance posture, and firms are welcome to cite it as one piece of that posture — but Lekhya doesn't position it, and firms shouldn't treat it, as a standalone answer to DPDP Act compliance, which rests on far more than how staff log in.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit workflow & automationSingle sign-on for audit firms: why it matters more at 80 engagements than at eightBelow a certain headcount, SSO is a convenience. Above it, it's the only realistic way offboarding actually happens on the day someone leaves.
- Audit data & extractsHandling client data securely during fieldworkPen-drive discipline, who can open the shared drive, and what happens to the client's data after sign-off: the practical hygiene that protects a firm handling someone else's accounting records.
- Technology, data & AI in auditCybersecurity considerations for a CA firm handling client dataA CA firm's client folder is a more concentrated target than any single client's own systems — one firm holds financial data for dozens of companies in one place.
- Technology, data & AI in auditClient data portal security: what to require before sharing a linkA portal link emailed without an expiry, sitting in someone's inbox for years, is a bigger exposure than most firms' entire password policy.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.