Log in
Compliance

DPDP Act and SMS OTP: Developer Compliance Guide (2027)

Indian developers face a hard May 2027 deadline for DPDP Act SMS compliance. Learn how to secure OTP consent, audit logs, and structure compliant data flows.

StartMessaging Team
DPDP Act and SMS OTP: Developer Compliance Guide (2027)

A Bengaluru-based fintech startup was onboarding 10,000 new users a week. Then, a single user complaint hit the newly operational Data Protection Board in Q1 2026. Within forty-eight hours, the developers were in an emergency Slack channel. They weren’t debugging a server crash; they were hunting for where phone numbers, OTP logs, and SMS delivery receipts were stored, realizing they had no documented consent records. The cost of that lesson? A settlement in the ₹15 crore range.

For years, developers in the Indian startup ecosystem built user verification flows with a simple checklist: accept a phone number, trigger an SMS through an API, and log the outcome in a database. If the delivery failed, you checked the logs to see the recipient number and the error code. But as the Digital Personal Data Protection (DPDP) Act’s enforcement timeline approaches its final phase, these standard practices are now high-risk compliance failures. Every Indian application that sends an SMS OTP is processing personal data, and developers must fundamentally redesign how they handle verification pipelines in accordance with general OTP data privacy principles before the May 2027 hard enforcement deadline.

What the DPDP Act Actually Is and Why OTP Developers Need to Care

The Digital Personal Data Protection Act (DPDP Act) 2023, along with the DPDP Rules notified on November 13, 2025, represents India’s first comprehensive legal framework for data privacy. Similar in scope to the European Union’s GDPR, the DPDP Act governs how companies collect, process, store, and delete personal data. However, the DPDP Act introduces distinct compliance dynamics that directly affect developer operations. While GDPR allows for processing under “legitimate interest” or “performance of contract” in broad ways, the DPDP Act centers itself heavily on explicit, consent-driven mechanisms, leaving very narrow exemptions.

For any developer building or maintaining an application in India, a phone number is not just a database column or a unique login index. Under Section 2(t) of the DPDP Act, a phone number is classified as “personal data” because it can directly identify an individual. Consequently, the act of collecting a phone number and transmitting a 6-digit OTP code constitutes “processing.” The logs generated by this action—including the recipient’s phone number, the carrier status, timestamps, and delivery channels—are records of personal data processing that must be protected, minimised, and eventually purged.

The Phased Enforcement Timeline

The Ministry of Electronics and Information Technology (MeitY) structured the implementation of the DPDP Act in three distinct phases to give the industry time to adjust. However, this transition period is closing fast:

  • Phase 1 (November 13, 2025): The Data Protection Board of India (DPBI) was established, and the primary penalty framework became active. This allowed the board to accept user complaints and initiate enforcement actions for data security lapses.
  • Phase 2 (November 13, 2026): The Consent Manager framework becomes fully operational. This introduces a unified platform where Indian citizens can view, modify, and withdraw their data consents across different apps.
  • Phase 3 (May 13, 2027): Full substantive enforcement begins. By this date, all legacy data collections, backend log pipelines, third-party vendor agreements, and user verification portals must be compliant.

Statutory Penalties Under the DPBI

The penalties for non-compliance are severe and designed to deter negligent data handling. Unlike GDPR, which structures fines as a percentage of global turnover, the DPBI enforces fixed-cap penalties per category of violation:

Violation CategoryMaximum Penalty under DPDPPrimary Trigger
Failure to take reasonable security safeguardsUp to ₹250 crorePlaintext OTP log leaks, unsecured database backups
Failure to notify the Board of a personal data breachUp to ₹150 croreUnreported data leaks or compromised SMS API keys
Non-fulfillment of obligations in relation to childrenUp to ₹200 croreVerification of under-18s without parental consent
Failure to honor Data Principal rightsUp to ₹50 croreIgnoring user deletion or data access requests

These fines are assessed per instance of systemic failure rather than per affected user. A startup running an unsecured verification database faces the same statutory limits as an enterprise. The DPBI has already initiated first-phase enforcement actions in Q1 2026 against mid-sized platforms in fintech, edtech, and gaming, demonstrating that startups are not exempt from audit.

How DPDP Differs from GDPR for SMS Verification

Developers who assume that their GDPR-compliant setup is sufficient for India will run into regulatory trouble. The DPDP Act has three major structural differences that impact OTP verification flows:

  1. Consent is the Primary Lawful Basis: Under GDPR, developers can justify sending an authentication OTP under “performance of contract” or “legitimate interest.” Under the DPDP Act, there is no generic “legitimate interest” exemption for private commercial applications. You must secure explicit, affirmative consent for processing a user’s phone number.
  2. Age of Consent is 18: GDPR allows member states to set the age of digital consent between 13 and 16. In India, anyone under the age of 18 is classified as a child. If your application verifies users under 18 via SMS OTP, you must build a separate verifiable parental consent flow.
  3. Strict Bilateral Processing Agreements: The DPDP Act explicitly holds the Data Fiduciary (the app owner) responsible for all actions of the Data Processor (the SMS provider). If your SMS gateway leaks logs, your business faces the primary penalty.

The Three DPDP Obligations That Directly Affect OTP Flows

Implementing compliance requires moving beyond a general privacy policy. Developers must modify the front-end user experience, the back-end logging pipelines, and the data schema of their verification databases. For a broader overview of how data laws reshape this ecosystem, see our primary guide on the DPDP Act and OTP compliance in India.

The following three obligations represent the core areas where standard OTP workflows violate the DPDP Act.

The DPDP Act demands that consent must be free, specific, informed, unconditional, and given through a clear affirmative action. In practice, this invalidates several common user interface designs. You can no longer rely on implied consent, such as a caption stating “By entering your number, you agree to our Terms of Service.” Bundling consents is also prohibited; you cannot require a user to consent to promotional SMS updates as a condition for receiving an authentication OTP.

To comply, your phone number input screen must separate identity verification from marketing opt-ins. The user must actively check a box to authorize the collection of their phone number for authentication.

The code example below demonstrates a compliant interface structure using a React component that isolates authentication consent:

import React, { useState } from 'react';

export function SmsVerificationConsent() {
  const [phoneNumber, setPhoneNumber] = useState('');
  const [authConsent, setAuthConsent] = useState(false);
  const [marketingOptIn, setMarketingOptIn] = useState(false);
  const [error, setError] = useState('');

  const handleSendOtp = async (e) => {
    e.preventDefault();
    if (!authConsent) {
      setError('You must consent to identity verification to receive an OTP.');
      return;
    }
    setError('');
    
    // Call backend API to trigger OTP
    await fetch('/api/auth/send-otp', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        phoneNumber,
        consents: {
          auth: authConsent,
          marketing: marketingOptIn,
          timestamp: new Date().toISOString()
        }
      })
    });
  };

  return (
    <form onSubmit={handleSendOtp} className="verification-form">
      <label htmlFor="phone">Enter Phone Number</label>
      <input
        id="phone"
        type="tel"
        placeholder="+91 99999 99999"
        value={phoneNumber}
        onChange={(e) => setPhoneNumber(e.target.value)}
        required
      />
      
      <div className="consent-checkboxes">
        <label className="checkbox-container">
          <input
            type="checkbox"
            checked={authConsent}
            onChange={(e) => setAuthConsent(e.target.checked)}
          />
          I consent to receive an OTP via SMS to verify my identity. 
          Read our <a href="/privacy-notice#otp" target="_blank">OTP Processing Notice</a>.
        </label>

        <label className="checkbox-container">
          <input
            type="checkbox"
            checked={marketingOptIn}
            onChange={(e) => setMarketingOptIn(e.target.checked)}
          />
          (Optional) I agree to receive marketing updates on WhatsApp and SMS.
        </label>
      </div>

      {error && <p className="error-message">{error}</p>}
      <button type="submit" disabled={!authConsent}>Verify Number</button>
    </form>
  );
}

This React component provides a visual structure for capturing separate and informed permissions before calling the backend. It ensures the consent data is verified client-side before any OTP API endpoints are triggered.

After the user checks the checkbox and submits the form, the frontend posts the explicit verification request. The backend system receives this consent payload and saves it to the user’s audit trail to prove compliance to the regulatory board.

Obligation 2: Data Minimisation and Purpose Limitation for OTP Logs

Many engineering teams default to logging entire API payloads during debugging. When an SMS provider handles an OTP, they return a delivery report (DLR) that contains the recipient’s phone number, carrier network, message content, and status. If you store these logs in plaintext indefinitely, you are violating the data minimisation principle, which limits retention to the time necessary to fulfill the purpose.

A compliant database schema must hash the phone number and discard the plaintext message text once the verification window expires. For debugging delivery failures, you only need to store a hashed identifier (to trace repeating numbers) and the carrier-returned metadata.

The code example below shows a TypeScript schema for database records that implements data minimisation for logging:

import { Schema, model } from 'mongoose';
import crypto from 'crypto';

interface IOtpVerificationLog {
  phoneHash: string;          // Hashed phone number for fraud analysis
  requestId: string;          // Gateway tracking reference
  channel: 'sms' | 'whatsapp';
  status: 'pending' | 'verified' | 'failed' | 'expired';
  carrierCode?: string;       // For debugging carrier routing
  attemptCount: number;
  createdAt: Date;
  expiresAt: Date;            // TTL index for automatic deletion
}

const otpLogSchema = new Schema<IOtpVerificationLog>({
  phoneHash: { type: String, required: true, index: true },
  requestId: { type: String, required: true, unique: true },
  channel: { type: String, enum: ['sms', 'whatsapp'], required: true },
  status: { type: String, enum: ['pending', 'verified', 'failed', 'expired'], default: 'pending' },
  carrierCode: { type: String },
  attemptCount: { type: Number, default: 0 },
  createdAt: { type: Date, default: Date.now },
  expiresAt: { type: Date, required: true, index: { expires: 0 } } // MongoDB TTL Auto-Purge
});

// Helper to generate a consistent hash for fraud detection and rate limiting
export function generatePhoneHash(phoneNumber: string): string {
  const salt = process.env.OTP_HASH_SALT || 'fallback-security-salt';
  return crypto
    .createHmac('sha256', salt)
    .update(phoneNumber.trim().replace(/[^0-9]/g, ''))
    .digest('hex');
}

export const OtpVerificationLog = model<IOtpVerificationLog>('OtpVerificationLog', otpLogSchema);

This Mongoose database schema defines the fields required for debugging carrier delivery while replacing plaintext recipient identifiers with SHA-256 hashes. It relies on the database engine’s native index timers to automatically purge older logging metadata in alignment with OTP security best practices.

By utilizing a database-level Time-To-Live (TTL) index set to 90 days, the database automatically deletes old records. Hashing the phone number with a salted SHA-256 function prevents plaintext exposure if the log database is breached, while still allowing the system to run rate-limiting checks and detect SMS pumping fraud attempts.

Obligation 3: Data Principal Rights and Grievance Handling

Under Section 11 to 14 of the DPDP Act, users are granted explicit rights to access, correct, and erase their personal data. If a user deletes their account and requests the erasure of their records, you must remove their phone number not only from the active user table but also from all historical verification logs, archived databases, and third-party SMS provider caches.

Additionally, the DPDP Rules mandate that every application must establish a clear grievance redressal mechanism. The details of a designated Grievance Officer must be easily accessible in the application interface, and the team must respond to user requests within 30 days.

[User Deletion Request] 
      │
      ▼
┌──────────────┐      ┌────────────────────────┐      ┌───────────────────────────┐
│ User Service │ ───> │   SMS API Gateway      │ ───> │    OTP Log Database       │
│              │      │                        │      │                           │
│ Delete User  │      │ Call /delete-recipient │      │ Purge Plaintext Records   │
│ Record       │      │ to scrub provider logs │      │ (Retain salted hashes)    │
└──────────────┘      └────────────────────────┘      └───────────────────────────┘

This data deletion flow visualizes how a user-initiated delete event propagates from your central profile service down through the external carrier gateways and your local log databases. It ensures no orphaned personal identifiers remain in secondary storage systems.

When building this deletion pipeline, your user management service should loop through your SMS gateway’s deletion endpoints to remove any stored logs at the carrier level. If you are using a provider that does not offer programmatic log purging, you cannot guarantee compliance with user erasure requests. This ability to purge log tables programmatically is a key differentiator when evaluating OTP API pricing and compliance options in India.

Special Cases: Children, Fintech, and Multi-Tenant Platforms

Certain industries and user demographics face strict regulatory standards under the DPDP Act, requiring custom software architectures.

The DPDP Act imposes a ban on processing children’s personal data without verifiable parental consent. If your application targets or serves users under 18—such as edtech platforms (see our guide on student verification for edtech), gaming apps, social media, or online entertainment—you cannot directly register them with a standard SMS verification flow.

To build a compliant age gate, developers must implement a dual-OTP verification process:

  1. Age Declared: The user enters their date of birth. If they are under 18, the UI disables the standard signup field.
  2. Parental Input: The app prompts the user to enter a parent or guardian’s phone number.
  3. Verification: The system sends an OTP to the parent’s phone number with a clear SMS context: “Your child is registering for [App]. Enter code [123456] to grant permission.”
  4. Audit Log: The backend logs the parent’s verification, the timestamp, and the consent authorization, referencing it to the child’s profile.

This parental verification flow must be treated as a separate data schema to ensure that the child’s phone number is never processed without the verification event of the parent.

Fintech and BFSI: Balancing DPDP and Sector Regulations

Financial developers operate in a complex environment where data privacy requirements conflict with banking mandates. The Reserve Bank of India (RBI) and the Securities and Exchange Board of India (SEBI) require financial institutions to retain transaction records, including authentication histories, for 7 to 10 years to combat money laundering.

To balance these obligations, developers should separate transactional logs from operational logs:

  • Operational Logs: Delivery reports, provider latency metrics, and verification attempt records should have a short 90-day retention period.
  • Audit Trails: The record linking an OTP to a financial action should store only the transaction ID, the status, the gateway request reference, and a hashed representation of the identity. The plaintext phone number should be retrieved only from the encrypted, access-controlled primary profile database.
  • SMS Provider DPA: Ensure your gateway provider stores financial transaction messages under strict data sovereignty rules, maintaining all processing nodes within India.

For a deeper dive into financial verification rules, read our developer guide on the RBI Authentication Directions. Additionally, you can learn more about sector-specific verification guidelines in our post on OTP verification for Indian fintech applications.

B2B SaaS and Multi-Tenant Platforms

If your application provides software-as-a-service to corporate clients who manage their own end-users, you are classified as a Data Processor under the DPDP Act. Your clients are the Data Fiduciaries. The law assigns primary liability to the Data Fiduciary, meaning your corporate customers will require proof of compliance before integrating your API.

Under Section 8, you must execute a formal Data Processing Agreement (DPA) with your customers. The agreement must state that:

  • You process phone numbers and trigger OTPs solely on the instructions of the Data Fiduciary.
  • You will implement data erasure within the SLA boundaries (typically 30 days) when the client requests it.
  • You maintain strict security standards to prevent data breaches in multi-tenant databases.

When managing high-volume enterprise queues, developers should segregate message logs by tenant. This separation ensures that an erasure request from one client does not touch or compromise the database tables of another tenant. For architectural patterns on handling multi-tenant verification pipelines, refer to our guide on multi-tenant OTP architecture for B2B SaaS.

The Developer Compliance Checklist (Pre-May 2027)

To align your systems with the DPDP requirements before the May 2027 deadline, audit your current verification workflows against this step-by-step checklist:

  1. Map Every Phone Entry Point: Document every location in your codebase where a phone number is collected—including registration, login, profile updates, checkout, and password recovery.
  2. Audit the Log Databases: Review your production databases, log storage, error monitoring platforms (like Sentry or Bugsnag), and analytics dashboards to ensure no plaintext phone numbers or OTP codes are written to logs.
  3. Implement Log Hashing: Update your logging middleware to replace plaintext phone numbers with salted hashes, and ensure that generated OTP values are hashed immediately server-side before verification.
  4. Set Up Automatic Purging: Implement scheduled database cleanup scripts or database TTL rules to automatically delete operational verification logs after 90 days.
  5. Build a User Erasure API: Create an internal service endpoint that programmatically deletes or anonymizes a user’s phone number across all active databases, archives, and third-party SMS provider portals on request.
  6. Add Grievance Officer Details: Update your application’s settings panel, footer, and privacy notice with the name, email address, and response timeline of your Grievance Officer.
  7. Verify Age Gate Logic: If your application is accessible to users under 18, build parental verification workflows to prevent processing minors’ data without authorization.
  8. Execute DPDP-Compliant DPAs: Review your contracts with third-party SMS providers, ensuring they have executed a Data Processing Agreement that enforces data residency inside India and provides log-erasure APIs.

What Happens if You Don’t Comply

Ignoring the DPDP compliance timeline poses a significant risk to your business. The Data Protection Board of India has indicated that its enforcement model will prioritize citizen complaints over proactive regulatory audits. In a highly competitive digital market, a single public complaint can trigger an investigation into your startup’s backend architecture.

If the DPBI discovers that your platform has been processing phone numbers without consent or storing logs in plaintext, the penalties are assessed per category of violation. The board examines the nature, gravity, duration, and compliance history of the business.

┌──────────────────────────────────────────────────────────┐
│             Startup Compliance Risk Matrix               │
└──────────────────────────────────────────────────────────┘
  High ▲
       │  [High Risk]                         [Critical Compliance Failures]
       │  • Implicit consent flows            • Indefinite plaintext log storage
       │  • Mixed marketing/auth logs         • No user deletion mechanism
R      │                                      • No Grievance Officer details
I      │
S      │  [Medium Risk]                       [Compliant Posture]
   ▲   │  • Third-party SMS without DPA       • Hashed operational log keys
   │   │  • Legacy data unmapped              • Automatic 90-day TTL purges
   │   │                                      • Isolated parental flows
  Low  │
       └───────────────────────────────────────────────────────────────────►
        Low                                                            High
                             COMPLIANCE MATURITY

This compliance maturity diagram maps the operational risk factors faced by startups based on their database architecture and interface layouts. Moving from implicit frameworks to hashed, automated pipelines reduces overall regulatory exposure.

Many startup founders and product managers plan to delay compliance changes until early 2027. However, modifying production log schemas, migrating legacy data tables, rewriting user consent interfaces, and auditing third-party supplier pipelines typically takes three to six months of development time. Starting your migration in March 2027 leaves zero buffer for testing, increasing the risk of data delivery interruptions and exposing your business to early enforcement actions.

Frequently Asked Questions

Q: Does the DPDP Act apply to startups, or only large companies?

A: The DPDP Act applies to all entities that process digital personal data within India, regardless of the company’s size, funding, or valuation. There are no blanket exemptions for early-stage startups. If you collect and verify Indian phone numbers, you must comply with the consent, data minimisation, and user rights mandates.

Q: Do I need explicit consent to send an OTP, or is it implied by the user entering their phone number?

A: Implied consent does not meet the requirements of the DPDP Act. The user entering their phone number does not grant you the right to process their data. You must include an unchecked checkbox that clearly states the user consents to receiving an OTP for verification purposes, and this consent must not be bundled with terms or marketing updates.

Q: How long can I keep OTP delivery logs under the DPDP Act?

A: The DPDP Act states that personal data can only be retained for as long as necessary to fulfill the stated purpose. For operational debugging and troubleshooting, a retention period of 90 days is standard. For security monitoring and fraud detection, retaining hashed records for 12 months is defensible, provided the purpose is documented.

Q: Does my SMS provider need to sign a Data Processing Agreement?

A: Yes. Because you are the Data Fiduciary and the SMS provider is the Data Processor, you are responsible for any data leaks or compliance failures on their network. Your provider must sign a Data Processing Agreement that aligns with the DPDP Act, guaranteeing that they will protect user data, locate processing nodes in India, and honor erasure requests.

Q: What is the difference between the DPDP Act and the RBI Authentication Directions 2025?

A: The RBI Authentication Directions are sector-specific mandates that govern multi-factor authentication for payment processing. The DPDP Act is a broad data privacy law that covers how personal data—such as phone numbers—is collected, stored, and processed across all sectors. You must comply with both laws if you build fintech applications.

Q: Is there a safe harbour for OTP sending under the DPDP Act?

A: There is no safe harbour or general exemption for authentication messages. Because verifying an identity requires collecting and processing a phone number, all OTP and SMS workflows fall within the scope of the DPDP Act. Failing to secure consent or storing logs insecurely exposes your business to regulatory action.

Aligning Your Verification Flow with StartMessaging

Achieving compliance before the May 2027 deadline does not require building your verification infrastructure from scratch. StartMessaging is designed as a DPDP-compliant verification platform, helping developers meet regulatory standards:

  • Data Residency: All message processing servers and log databases are hosted locally in India, keeping your traffic aligned with national sovereignty expectations.
  • Automatic Log Anonymisation: StartMessaging automatically hashes phone numbers and purges plaintext log contents within 90 days of sending, helping your system comply with data minimisation guidelines.
  • Developer-Friendly DPA: Our standard terms of service include a DPDP-compliant Data Processing Agreement, reducing legal review times during onboarding.
  • Log Erasure APIs: StartMessaging provides developer endpoints to delete verification histories for individual numbers, allowing you to honor user erasure requests instantly.

If you are currently evaluating your compliance posture or looking to migrate from a legacy provider, you can sign up for an account today. Transition your verification workflows to a compliant framework with minimal changes to your codebase.

Ready to secure your OTP pipelines? Create a free account on StartMessaging to start sending compliant OTPs with our developer API.

S

StartMessaging Team

StartMessaging Team

Related posts