Privacy & DPDP Compliance
Verify with counsel. This page is an engineering interpretation of the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 (notified November 2025, with most obligations phased in over roughly 18 months). It is not legal advice. Dates, deadlines and interpretations below must be confirmed by Indian privacy counsel before they are relied on in contracts or product copy.
This page deepens the data-governance row of §7 of the architecture (ADR-007). Security controls are in the security overview.
1. Roles under the Act
| Party | DPDP role | For which data |
|---|---|---|
| Tenant (employer) | Data Fiduciary | Employee personal data processed in Spyrl (HR, attendance, payroll, location, biometrics) |
| Spyrl | Data Processor for the tenant | The same data, processed only on the tenant's documented instructions under a Data Processing Agreement (DPA) |
| Spyrl | Data Fiduciary | Its own data: tenant admin contacts, sign-up leads, billing contacts, website analytics |
| Employees | Data Principals | Their own data |
| Spyrl sub-processors (AWS, SES, MSG91, Rekognition, Expo, Sentry, Grafana) | Processors engaged by Spyrl | Listed in the processor register (section 9) |
Consequence: most DPDP duties fall on the tenant. Spyrl's job is to make compliance the default (features, defaults and records), to process only on instruction, to protect data, and to help the tenant meet requests and breach duties.
2. Obligation mapping
| DPDP requirement | What it means here | How Spyrl supports it | Owner |
|---|---|---|---|
| Lawful basis (consent, or a legitimate use under section 7) | Much employment processing can rely on the "employment" legitimate use (section 7(i)); consent remains appropriate for optional, intrusive processing | Each data purpose is tagged with its basis in configuration. Face verification and location tracking always require explicit consent in Spyrl, regardless of basis (ADR-007), because they are intrusive and optional by design | Tenant decides; Spyrl defaults |
| Notice (section 5 and Rules) | Clear, standalone, itemised notice of data, purpose, and how to exercise rights and complain to the Board | A tenant-editable privacy notice template shown at activation and kept in ESS; versioned; acknowledgement recorded. Available in English first, with the local languages the Act's notice rules allow as they ship (i18n) | Tenant content; Spyrl template |
| Consent (section 6) | Free, specific, informed, unambiguous, with a clear affirmative action; as easy to withdraw as to give | Consent records per purpose (section 4); withdrawal in ESS with the same number of taps; no pre-ticked boxes; no bundling with employment acceptance | Spyrl feature |
| Purpose limitation | Use data only for the stated purpose | Purpose tags on fields (schema classification); biometrics used only for attendance verification; GPS used only for field attendance, visits and travel; analytics on aggregated data only | Spyrl design |
| Data minimisation and accuracy | Collect what is needed; keep it correct | Aadhaar optional and masked; employee change requests for corrections; import validation | Both |
| Security safeguards | Reasonable safeguards: encryption, access control, monitoring, logs | Security overview: envelope encryption, RBAC with scopes, audit, monitoring, log retention of at least one year for security logs as the Rules require (verify) | Spyrl |
| Breach notification | Fiduciary informs the Data Protection Board and each affected data principal without delay; a detailed report to the Board within 72 hours (Rules; verify) | Spyrl notifies the tenant without undue delay and within 24 hours of confirming a breach affecting their data, with facts needed for both notices; template notices in the tenant console | Spyrl → tenant |
| Retention and erasure | Erase when the purpose is served and no law requires retention | Retention schedule (section 6) enforced by jobs; erasure workflow respecting statutory retention | Both |
| Data principal rights | Access/summary, correction, completion, update, erasure, grievance redressal, nomination | Section 3 | Tenant responds; Spyrl provides tools |
| Processors | Fiduciary must use processors under a valid contract | DPA template with Spyrl's sub-processor list, change notice, audit rights, deletion on termination | Spyrl |
| Children (section 9) | Verifiable parental consent for anyone under 18; no tracking or targeted advertising | Not applicable by design: employees are adults. Imports block DOB under 18; an explicit tenant exception is required for lawful adolescent employment, and then face and location tracking are disabled for that employee and parental consent is the tenant's duty | Spyrl default |
| Cross-border transfer | Allowed except to countries the government restricts | All tenant data stored in India (ap-south-1, DR in ap-south-2). Some processors relay minimal data abroad (push notifications, error tracking with redaction); listed in the processor register | Spyrl |
| Significant Data Fiduciary | Extra duties (DPO, DPIA, audits) if notified | Unlikely for Spyrl or its SME tenants; the DPIA process (section 7) is used anyway | — |
| Grievance contact | Fiduciary publishes a contact for questions and grievances | Tenant configures a grievance officer contact shown in ESS; Spyrl publishes its own for fiduciary data | Both |
3. Data principal rights
| Right | Employee action in ESS | Tenant workflow | Spyrl tooling |
|---|---|---|---|
| Access / summary | "My data" request | HR approves; the system compiles | Generates a summary (categories, purposes, processors) plus a machine-readable export of the employee's own records, excluding other people's data and internal notes as permitted |
| Correction / completion / update | Profile change request | HR approves (emp.change_request.approve) | Audit of before/after |
| Erasure | "Delete my data" request | HR reviews against statutory retention; erases what is not legally required | Erasure job: deletes or anonymises non-required fields and documents; marks retained records with the legal basis and the scheduled deletion date |
| Withdraw consent | Toggle in Settings → Privacy | None needed | Stops processing immediately (face template deleted within 24 h; tracking disabled at the next app sync) |
| Grievance | Contact shown in ESS | Grievance officer responds | Request tracking with due dates |
| Nominate | Nominee form | — | Stored with the profile |
Every request is a tracked case with a due date. The Act and Rules set response expectations; Spyrl defaults to a 30-day response target with reminders at day 15 and day 25 (verify the binding timeline with counsel).
4. Consent flows
4.1 Biometric (face) consent
Rules:
- No penalty for declining. A fallback attendance method must exist; the product will not let a policy make face verification the only method.
- Consent at a kiosk is captured on the employee's own phone (ESS) or on a paper form uploaded by HR, not by the kiosk operator tapping "agree".
- Raw enrolment images are discarded after template creation; punch selfies are kept 180 days as attendance evidence.
4.2 Location consent (field force)
| Step | Behaviour |
|---|---|
| Notice and consent | In-app screen explaining: tracking only between punch-in and punch-out, sampling interval, who sees it (own reporting chain with ffm.tracking.read), retention (raw 90 days, then aggregates), how to withdraw |
| OS permission | Requested after the in-app consent, with the platform's own justification text; background location only for tracking mode |
| Indicator | A persistent notification and an in-app banner while tracking is on |
| Outside work hours | Tracking stops at punch-out or at shift end + grace, whichever is first, even if the app stays open |
| Point-to-point mode | A lower-intrusion option: location only at punch and visit events, no continuous trail. Tenants should prefer it where continuous tracking is not needed |
| Withdrawal | Switches the employee to point-to-point or office attendance; managers are told only "tracking not active", not why |
| Store listings | Data-safety declarations must state location and photo collection accurately (the reference product's listings contradict themselves, see research) |
Punch geo-tagging for office attendance (a single location at punch time to check the geo-fence) is part of the attendance purpose; it is covered by the privacy notice and does not need the tracking consent.
5. Consent record
consent_record:
tenant_id: uuid
employee_id: uuid
purpose: biometric.face | location.tracking | whatsapp.notifications | marketing.none
notice_version: "2026-11-v3"
status: granted | declined | withdrawn
captured_at: 2026-11-04T09:12:00+05:30
channel: ess_mobile | ess_web | paper_upload
device_id: optional
evidence_ref: optional # uploaded form for paper consent
withdrawn_at: optional
Records are append-only (a new row per change) and exportable by the tenant.
6. Retention schedule
Proposed defaults. Tenants may lengthen within legal limits or shorten where no statute requires retention. Statutory periods are examples to verify with counsel and the tenant's auditors.
| Data class | Default retention | Basis / note | Deletion method |
|---|---|---|---|
| Payroll runs, payslips, salary registers, statutory files | 8 years after the end of the financial year | Books of account and tax records (Companies Act and Income-tax practice; verify) | Object Lock expiry, then deletion job |
| Tax declarations and proofs | 8 years | Tax assessment periods (verify) | Deletion job |
| EPF/ESI/PT/LWF records | 8 years | Statutory registers (verify per statute and state) | Deletion job |
| Attendance day records and leave ledgers | 8 years (they drive pay) | Wage records (verify) | Deletion job |
| Raw punches | 3 years | Evidence for disputes; day records retained longer | Partition drop |
| Punch selfies | 180 days | Architecture §7 | Lifecycle rule |
| Face templates | Until consent withdrawal or exit + 30 days | Purpose ends | Delete + provider delete call |
| Raw GPS points | 90 days, then daily aggregates (kms, visit list) | Architecture §7 | Partition drop |
| GPS daily aggregates and visits | 3 years (used for claims) | Claims audit | Deletion job |
| Employee profile of ex-employees | Exit + 8 years for the statutory subset (name, IDs, dates, pay history); other fields deleted at exit + 1 year | Statutory and dispute limitation (verify) | Field-level erasure |
| Employee documents (KYC copies, certificates) | Exit + 1 year unless a statute requires longer | Minimisation | Deletion job |
| Claims and receipts | 8 years | Accounting | Deletion job |
| Audit log | 3 years online, then archived to 8 years for payroll-related events | Accountability; Rules require at least one year of logs (verify) | Archive and expiry |
| Security logs (auth, WAF, access, CloudTrail) | 1 year (minimum 180 days in India per CERT-In) | CERT-In; DPDP Rules (verify) | Lifecycle rule |
| Application logs / traces | 30 days / 14 days | Operations | Backend retention |
| Backups | 35 days PITR; monthly snapshots 12 months | DR | Expiry |
| Tenant data after offboarding | Export window + grace, then deletion within 30 days | Contract (client onboarding) | Deletion job + crypto-shredding |
7. DPIA triggers
A data protection impact assessment (a short template: data, purpose, necessity, risks, mitigations, residual risk, sign-off by the security lead and product owner) is required before building or enabling:
- Any new biometric processing or a new face provider.
- Any change to location collection (frequency, background mode, new purposes such as route optimisation).
- A new data class (for example health data for wellness features, or background verification).
- A new sub-processor that receives C3/C4 data, or any processing outside India.
- Automated decisions with effects on employees (for example auto-deductions from attendance anomalies, productivity scoring).
- Analytics that combine data across tenants, even aggregated.
- A change that broadens who can see C3/C4 data (new role grants, manager visibility changes).
- AI features that process employee personal data.
Tenants planning intrusive configurations (continuous tracking for all staff, face verification for office workers) get an in-product prompt suggesting they document their own assessment.
8. Breach handling (privacy view)
- Security incident process runs (security overview).
- Within 24 hours of confirming a personal-data breach, Spyrl informs each affected tenant's owner and grievance contact: what happened, data categories, affected principals (counts and lists), likely consequences, mitigations, and Spyrl contact.
- Spyrl provides draft notices for the tenant to send to the Data Protection Board and to affected employees, and data to support the detailed report (72-hour expectation under the Rules; verify).
- CERT-In reporting within 6 hours where applicable is handled by Spyrl for its systems.
- Spyrl records the breach in its register with the timeline and corrective actions.
9. Processor register (Spyrl sub-processors)
| Processor | Purpose | Data | Location |
|---|---|---|---|
| AWS (RDS, S3, ECS/EC2, SES, Rekognition, KMS) | Hosting, storage, email, face verification | All tenant data | India (ap-south-1, ap-south-2) |
| MSG91 / Gupshup | SMS and WhatsApp | Phone numbers, template variables | India (Meta relays WhatsApp; verify) |
| Expo | Push notification relay | Push tokens, short message text | Outside India (minimal payload) |
| Sentry | Error tracking | Redacted errors, pseudonymous IDs | Verify region; redaction applied |
| Grafana (Cloud or self-hosted) | Observability | Redacted logs, traces, metrics | India region or self-hosted (verify) |
| Google / Mappls | Maps and geocoding | Addresses, anonymous coordinates | Varies (Mappls India) |
| Razorpay | Subscription billing | Tenant billing contacts | India |
| KYC aggregator (optional, R3) | PAN, DigiLocker, bank verification | PAN, name, bank account | India |
Tenants receive 30 days' notice of a new sub-processor and may object under the DPA.