Summary
Vetanly's enterprise customers had started attaching DPDP addenda to renewals, and a large customer's procurement team had paused a deal over an unanswered questionnaire. Leadership gave us one brief: be able to prove compliance by the end of the quarter, without freezing the product roadmap.
“Compliance” turned out to be a product feature. Our customers' admins now run retention, exports and deletion for their own tenants, and that has closed deals.
The company
Vetanly is a Bengaluru-based HR and payroll platform for companies with 50 to 5,000 employees. Its product covers payroll and statutory filings, attendance with geo-tagged selfie check-in, leave, reimbursements and an employee self-service (ESS) mobile app. The ESS app also offered a salary-advance feature through a lending partner.
| Customers | 1,420 paying companies; 212 churned in the last three years |
|---|---|
| People in the system | 3.4 lakh active employees, 41,000 records from churned tenants, 11,000 customer admin users, 2.1 lakh ESS app accounts |
| Personal data held | Name, contact, PAN, Aadhaar (in KYC uploads), bank account, salary and deductions, attendance location, selfie images, leave and medical certificates, dependants for insurance (including minors) |
| Stack | AWS Mumbai; PostgreSQL (shared schema, tenant ID), S3 document store, Elasticsearch, Kafka, Redshift with a BI layer; 38 engineers in 6 squads |
| Third parties | 23 sub-processors, including SMS and email gateways, product analytics, support desk, CRM, billing, e-sign, the lending partner and cloud services |
What we found in the first three weeks
Discovery combined automated scans with interviews of all six squads, support, sales and finance. Schema and object-store scanners tagged 1,180 columns and 31 S3 prefixes as personal data. The interviews turned up the stores that scanners can't see: spreadsheets, BI extracts and support attachments.
Uploads were stored unmasked. A debug logger wrote request bodies, so Aadhaar and PAN reached application logs and the search cluster. This is a Rule 6 safeguards gap with the highest penalty exposure.
Employers had not instructed this purpose; Vetanly had decided it for its own revenue. That made Vetanly a fiduciary for this flow, with no notice and no consent.
Customer contracts promised breach notice “within 7 days”. No runbook, no severity model, no templates, and on-call staff didn't know who decides to notify.
That is below the one-year minimum in Rule 6(1)(e) and Rule 8(3). Logs were also mutable, so they could not serve as evidence.
These included BI extracts on shared drives, support-desk attachments containing payslips, a legacy S3 bucket from a 2021 migration, and the selfie images used for attendance.
41,000 employee records from 212 former customers had no purpose left and no retention basis.
Product analytics received employee emails and phone numbers as event properties.
It was not itemised, not standalone and had no grievance contact. The ESS app had no privacy settings screen at all.
The median time to close a request was 19 days. Nothing separated requests Vetanly should answer from those it should forward to the employer.
The decision that unlocked everything: fiduciary or processor?
We listed 31 distinct processing purposes and assigned a role and lawful basis to each. That one table decided who gives notice, who answers a rights request, who notifies whom after a breach, and which purposes need consent at all.
| Purpose (examples) | Vetanly's role | Basis | Consequence |
|---|---|---|---|
| Payroll, statutory filings, attendance, leave | Processor | Employer's employment purposes | Act only on customer instructions; customer gives notice |
| Dependant details for group insurance | Processor | Employer's purpose; guardian data handled by employer | Minimise; no use beyond insurance enrolment |
| ESS app account and login | Fiduciary | Voluntarily provided for a specified purpose | Vetanly's own notice and grievance contact |
| Salary-advance referral to lending partner | Fiduciary | Consent | Purpose-level opt-in; minimum fields shared |
| Product analytics | Fiduciary | Consent; pseudonymised by default | Identifiers removed from events |
| Customer admin accounts, billing, support, CRM | Fiduciary | Contract and voluntarily provided | Retention tied to the account lifecycle |
Of the 31 purposes, 24 were processor purposes and 7 were fiduciary. The seven were where the real risk sat. They were also where Vetanly could act on its own authority, without waiting for 1,420 customers.
The 16-week plan
Our five-person team (an engagement lead, a privacy specialist, two product engineers and a security engineer) worked inside Vetanly's squads. Vetanly committed one platform engineer full-time and product-owner time for decisions. In total, the programme used about 22% of one quarter's engineering capacity.
The first fix shipped in week 4, before the gap report was final. The debug logger was switched off and the four log streams were purged and re-indexed. Waiting for a perfect plan would have left the highest-exposure gap open for another month.
What we built
1. A live data map, not a spreadsheet
Scanners run weekly against PostgreSQL, S3, Elasticsearch and Redshift. Each tags columns and prefixes by data category and flags anything new for review. The map feeds the record of processing, the retention engine and the erasure orchestrator, so it can't drift from reality without someone noticing.
2. Notices and a consent ledger
- A standalone, itemised notice for the ESS app and website, available in English, Hindi, Kannada, Tamil, Telugu and Marathi, with a plain-language summary first.
- A consent ledger service: append-only, with each event recording the data principal, purpose, notice version, channel and timestamp. Withdrawal is one tap in the app's new Privacy screen.
- A purpose gate on the event bus. Data reaches the lending partner only when the ledger shows an active consent for that purpose, and only the four fields the partner needs.
3. A Privacy Centre for customers' admins
Because Vetanly is a processor for most data, its customers needed the controls. A new admin console section lets each tenant set retention periods, export everything, delete leavers' records after their statutory period, view an access log, and see the sub-processor list. The DPA v2 sits there too, with DPDP-aligned clauses and a breach-notice commitment that works back from the Board's 72 hours.
4. Rights requests with routing
Requests come in through the ESS app, the web and email, and identity is verified by OTP to the registered number. The orchestrator then routes each request by role. Fiduciary requests are fulfilled automatically across 14 connected systems. Processor requests go into the employer's admin queue with a timer and reminders. Every step is written to the rights log.
5. Rule 6 safeguards
- Aadhaar tokenised in a separate vault; 2.3 lakh existing documents re-processed with the number masked to the last four digits.
- Field-level encryption for PAN and bank account numbers, with keys in a managed KMS and separated by environment.
- A shared log-redaction library added to all 11 services, with tests that fail the build if known identifiers appear in log output.
- Logs shipped to write-once storage and kept for 400 days, with access alerts on read.
- Just-in-time production access through SSO, plus quarterly access reviews.
6. Retention and erasure
Every data category got a retention period and its legal source. Payroll and tax records follow statutory record-keeping periods, selfie images are kept for 30 days, and the account lifecycle governs the rest. Churned tenants get a 90-day export window, then automated purge. The first run erased 41,000 records from 212 former customers and produced a certificate for each tenant.
7. Vendors
All 23 sub-processors were reviewed. Seven signed updated terms, two were replaced, and analytics events were stripped of direct identifiers. The public sub-processor page now updates from the same register the engineers use.
Architecture
Breach readiness against the 72-hour clock
We wrote a runbook around Rule 7. It sets a severity model, names who decides to notify, and gives templates for the Board's initial intimation, the detailed report, affected employees and affected customers. Because Vetanly is mostly a processor, the critical path runs through its customers, so the DPA now commits to notifying them within 24 hours of confirmation. That leaves each employer time to meet its own duty to the Board.
| Drill | Scenario | Board-ready report | Customers notified |
|---|---|---|---|
| Week 12 | Leaked support-desk API key, attachments exposed | 41 hrs | 29 hrs |
| Week 16 | Misconfigured S3 prefix, payslips for 3 tenants | 6 hrs | 4 hrs |
The first drill met the 72-hour limit with little margin. It also exposed two real problems: nobody could tell which tenants an attachment belonged to, and legal sign-off waited on a person who was travelling. Both were fixed before the second drill. Tenant tags were added to support attachments, and a named deputy now has sign-off authority.
Results
| Measure | Before | After |
|---|---|---|
| Data stores in the inventory | 28 | 47 (all) |
| Full Aadhaar occurrences in docs, logs, search | 2.3 lakh + 5 systems | 0 |
| Log retention | 30 days, mutable | 400 days, write-once |
| Median rights-request closure | 19 days | 31 hours |
| Rights requests with an audit trail | 0% | 100% |
| Time to Board-ready breach report (drill) | no process | 6 hours |
| Sub-processors on DPDP-aligned terms | 14 of 23 | 23 of 23 |
| Records without a retention basis | 41,000 | 0 (purged, certified) |
| Enterprise security questionnaire turnaround | 9 days | 2 days |
| Customers on DPA v2 after 45 days | n/a | 1,183 of 1,420 |
| Staff trained (role-based) | 0 | 140 of 140 |
The commercial effect came quickly. The paused enterprise deal closed in week 15, using the evidence pack in place of a 300-question questionnaire. Salary-advance referrals now go only to employees who opted in (34% of those eligible), and the partner's approval rate on referred applications went up.
Lessons for any SaaS company
Map roles before you write a single notice
Almost every downstream decision depends on whether you are the fiduciary or the processor for a given flow. Teams that start with the privacy policy end up rewriting it.
Build consent as a service, not a banner
A ledger keyed by purpose and notice version is what lets you prove consent, honour withdrawal everywhere and change a notice without losing history.
Delete is the hardest feature you will ship
Erasure touched 14 systems, including backups and vendors. If the data map isn't live, you can't know when deletion is complete.
Logs are personal data too
Rule 6 asks you to keep logs for a year. That only works if the logs don't become your largest store of unmasked identifiers.
Your processor posture is a sales asset
A Privacy Centre, a clear DPA and a public sub-processor list answer most procurement questions before they're asked.
What's next
Vetanly moved to our Managed Privacy Office retainer. That covers privacy review for every new feature and vendor, quarterly control tests, a grievance desk with service levels, and a standing breach on-call ahead of 13 May 2027. A third breach drill is scheduled before the deadline, this time run by Vetanly's own team with us observing.
Running a SaaS with thousands of customers?
We'll walk you through the role map and the first three fixes we'd make in your stack, in a 30-minute scoping call.
This reference case study describes a representative implementation for a mid-market Indian SaaS company. “Vetanly” is an illustrative name, and the figures show the scale and outcomes this programme is designed for. Statutory references are to the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified on 13 November 2025.