Before sharing a client data portal link, a firm should confirm four specific things: that the link or access expires on its own rather than remaining valid indefinitely, that data is encrypted both in transit and at rest with the vendor able to state this plainly rather than vaguely, exactly which individuals at the vendor can access uploaded data and whether that access is logged, and that the firm's own habit of sharing or forwarding the link doesn't quietly undermine all of the above.
1. Access expiry
A portal link that never expires is functionally a permanent password shared over email — if that email is ever compromised, forwarded, or simply sits in an old inbox that gets breached years later, the access is still live. Links and upload sessions should expire on a short, defined window, and any standing access should require active re-authentication, not a bookmarked link that works forever.
2. Encryption in transit and at rest
- Confirm the connection is TLS-encrypted — a plain visual check that the portal uses https is a minimum, not sufficient on its own.
- Ask specifically whether uploaded files are encrypted at rest on the vendor's storage, not just in transit, since a breach of stored data is a separate exposure from an intercepted upload.
- Ask who holds the encryption keys — a vendor holding both the data and the only keys to it has, in practice, full access regardless of what encryption-at-rest technically means.
3. Who at the vendor can see the data
| Question | Why it matters |
|---|---|
| Which roles at the vendor have access to uploaded client files? | Broad internal access multiplies the number of people who could mishandle or leak the data |
| Is that access logged, and can the firm request the log? | Without logging, 'who accessed this' is unanswerable after the fact |
| Are any sub-processors involved in storing or processing the upload? | A named sub-processor is a separate party the firm's data now passes through, often unmentioned unprompted |
4. The firm's own link-sharing hygiene
The most common portal-security failure isn't the vendor's — it's the firm forwarding the same upload link to a client's whole finance team over email instead of generating individual, trackable access, which means nobody can later say with confidence who actually used it.
- Generate a distinct access link or credential per client contact rather than one shared link for an entire team.
- Set an internal norm that portal links are never forwarded by the recipient without the firm's awareness.
- Periodically review which links or access grants are still live and revoke anything tied to a completed engagement.
How we think about this
Lekhya builds portal access around per-user, expiring links with a visible access log specifically so a firm can answer 'who touched this file and when' without having to take anyone's word for it after the fact.
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 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 auditCloud audit software and data residency: what to askWhere client data physically sits, who inside a vendor can see it, and the difference between an architectural guarantee and a policy that could change tomorrow.
- Internal audit & IFCUsing a SOC 1 Type II report in a statutory auditWhat a SOC 1 Type II report actually tells the auditor when a client outsources a process, how to test the complementary user entity controls it assumes, and what to do when none exists.
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.