Technical

Privacy Safeguards: The Foundation of Indian Data Protection

Jan 18, 20268 min read

Why we use privacy safeguards as our internal engine, and how it maps to DPDP and future needs.

India's DPDP Act requires 'appropriate technical and organisational measures' to protect personal data. Three words — appropriate, technical, organisational — do enormous interpretive work. What counts as appropriate? Appropriate for whom? Under what conditions? The answer lies in building a risk-based security programme calibrated to the actual threats Indian organisations face, not a compliance framework imported wholesale from a different regulatory environment.

The problem with framework sprawl

ISO 27001 certification costs ₹15-30 lakhs and takes 12-18 months for a first-time implementation. SOC 2 Type II, designed for US SaaS companies, requires an American auditor, American control frameworks, and controls that map to American cloud infrastructure expectations. Neither was designed with the Indian SMB in mind.

The result: Indian companies either skip security frameworks entirely (too expensive, too complex) or adopt them superficially (get the certificate, ignore the practice). Neither approach helps them understand or manage their actual data risk.

Five risk categories that matter for Indian data protection

  • Data exposure risk: Personal data stored without encryption, accessible to too many people, or retained longer than necessary. The most common category — and the one most directly addressed by DPDP's security safeguards obligation.
  • Legal basis gaps: Processing personal data without a documented legal basis (consent or legitimate use). Particularly acute for Indian companies that have historically processed data without formal consent infrastructure.
  • Data principal rights readiness: The inability to locate, retrieve, correct, or delete a specific individual's data in response to a rights request. A technical problem that requires an inventory foundation.
  • Breach readiness: The blast radius and response capability if a breach occurs. How much data would be exposed? How quickly could you notify? What evidence would you have of prior controls?
  • Access risk: Internal actors with excessive or undocumented access to personal data. The DPDP obligation around security safeguards explicitly covers insider risk, not just external threats.

Why automated detection beats checklists

The GDPR era in Europe produced a generation of companies that completed compliance checklists without becoming more secure. Privacy policies were drafted, DPAs were signed, consent banners were deployed — and breaches continued at the same rate. The problem was that checklists measure documentation, not control effectiveness.

Automated detection measures something different: whether your data is actually protected, not whether you have documented a policy saying it should be. A scanner that connects to your database and detects unencrypted Aadhaar numbers provides evidence that is qualitatively more valuable than a policy document asserting that Aadhaar numbers are encrypted.

The shift from compliance-as-reporting to compliance-as-continuous-signal is the most important architectural change in data protection practice. It mirrors the shift in infrastructure from batch health checks to continuous monitoring — driven by the same logic: you cannot manage what you do not measure, in real time.

The India-specific field problem

Indian personal data has fields that do not exist in US or EU compliance frameworks: Aadhaar numbers (12-digit unique identifier), PAN cards (10-character alphanumeric), voter IDs, driving licences in state-specific formats, and UPI IDs that map to bank accounts. A US-designed compliance tool that scans for Social Security Numbers and US credit card formats will not detect an Aadhaar number in your database.

Effective DPDP compliance requires detection capability that understands the Indian data landscape — not just a generic 'PII scanner' that catches email addresses and phone numbers while missing the government identifiers that carry the highest sensitivity and regulatory weight.

Building the foundation

  1. 1Asset inventory: know every system that stores personal data, who has access, and what field types are present.
  2. 2Sensitivity classification: apply the DPDP distinction between general personal data (name, email, phone) and sensitive personal data (Aadhaar, PAN, health, biometrics) — with different protection requirements for each.
  3. 3Access control review: identify roles and users with access to sensitive data that exceeds what their function requires.
  4. 4Retention enforcement: locate and remediate data that has exceeded its retention period — the most common and easiest-to-miss DPDP violation.
  5. 5Evidence collection: ensure every control check generates a timestamped, source-linked evidence record that can be retrieved on demand.

Takeaway

DPDP's 'appropriate measures' standard is deliberately flexible — it will be interpreted based on the state of available technology and the sensitivity of the data involved. Companies that build detection-first programmes — automated, continuous, evidence-generating — will find themselves ahead of both regulatory expectations and peer competition. The foundation is not a framework. It is a running inventory and a continuous signal.