Indiens DPDP Rules: utvecklingsarbetet som ska vara klart i maj 2027

Indien kungjorde Digital Personal Data Protection Rules, 2025 den 13 november 2025, som G.S.R. 846(E). De flesta regler som berör din produkt har ännu inte trätt i kraft. Enligt regel 1(4) träder reglerna 3, 5 till 16, 22 och 23 i kraft ”arton månader efter dagen för offentliggörandet i denna Gazette”. Räknar man arton månader framåt hamnar man på 13 maj 2027, lite drygt sju månader från i dag.

De reglerna omfattar information till användarna, säkerhet, anmälan av personuppgiftsincidenter, lagring och radering, barns uppgifter och begäranden om rättigheter. Regel 4, som låter Consent Managers registrera sig hos Data Protection Board, kommer tidigare: ett år efter offentliggörandet, alltså runt 13 november 2026. Regeringens tillkännagivande kallar det en infasning i etapper över 18 månader.

Den här artikeln vänder sig till CTO:er och produktchefer på indiska konsumentappar, fintechbolag, edtechbolag och e-handelsföretag, och på utländska företag med indiska användare. Lagen når behandling utanför Indien när den sker ”i samband med verksamhet som avser att erbjuda varor eller tjänster till Data Principals inom Indiens territorium” (avsnitt 3(b)). Det som följer är den programvara du måste bygga eller ändra. Det är ingen juridisk gapanalys: om du omfattas, vilka undantag som gäller och hur dina ändamål formuleras är frågor för en jurist.

Vem som faktiskt har utvecklingsarbete

Om all din kunddata ligger i en enda färdig SaaS-plattform kommer mycket av grundarbetet (kryptering, åtkomstloggar, raderingsjobb) från leverantörens färdplan. Ditt arbete gäller informationstexter, konfiguration och avtal. Läs avtalen: regel 6(1)(f) kräver att säkerhetsåtgärder skrivs in i dem, och ett exempel i regel 8 gör dig ansvarig för att din molnleverantör sparar data och loggar under det år som krävs.

Det tunga arbetet hamnar hos företag som kör egna appar och databaser, matar ett datalager från ett dussin pipelines och skickar med tredjeparts-SDK:er i mobilklienten. Det är större delen av Indiens konsumentinternet.

Vad varje regel kräver av din programvara

Information (regel 3)

Informationen ska vara ”begriplig fristående från all annan information” som du publicerar. Den ska minst innehålla ”en specificerad beskrivning av sådana personuppgifter”, det angivna ändamålet och en konkret beskrivning av de varor, tjänster eller användningsområden som behandlingen möjliggör. Den ska också tala om hur man återkallar samtycke, utövar sina rättigheter och klagar till Board.

I praktiken:

• Generera informationen från en datainventering. Fält för fält, kopplat till ändamål. ”Vi kan komma att samla in uppgifter som” är inte specificerat.
• Versionshantera varje informationstext. Varje samtyckespost måste peka på exakt den text användaren såg.
• Planera för språk. Avsnitt 6(3) i lagen kräver att en begäran om samtycke går att läsa på engelska eller på något av språken i Eighth Schedule till konstitutionen. Lagra informationen som översättningsbara strängar, inte som en PDF.
• Täck in befintliga användare. Avsnitt 5(2) kräver att de som samtyckte innan lagen trädde i kraft får information ”så snart det är rimligen praktiskt möjligt”. Det är ett utskick till hela din användarbas.

Samtycke, återkallelse och Consent Managers

Samtycke enligt avsnitt 6 ska vara specifikt och begränsat till de uppgifter ändamålet kräver. Avsnitt 6(10) lägger bevisbördan på dig: vid en tvist är det du som ska visa att information lämnades och samtycke inhämtades. Den meningen är skälet till att du behöver en samtyckesliggare i stället för en boolesk kolumn.

En fungerande liggare registrerar per användare och ändamål: informationsversion, tidsstämpel, kanal (webb, app, Consent Manager) och åtgärd (lämnat eller återkallat). Bara tillägg, inga ändringar.

Att återkalla samtycke ska vara lika enkelt som att lämna det (regel 3(c)(i), avsnitt 6(4)). Om samtycket var ett tryck under introduktionen kan återkallelsen inte vara ett mejl till supporten. Den måste också nå ut. Avsnitt 6(6) kräver att du upphör med behandlingen, och ser till att dina Data Processors upphör, inom rimlig tid. Samtyckestjänsten publicerar därför återkallelsehändelser till varje system och leverantör som agerar på det ändamålet: CRM, marknadsföringsplattform, analyspipeline.

En Consent Manager är en registrerad gemensam kontaktpunkt där en användare kan ”lämna, hantera, granska eller återkalla sitt samtycke” (avsnitt 6(7)). Enligt First Schedule måste den vara ett bolag registrerat i Indien med ett nettovärde på minst två crore (20 miljoner) rupier, dess plattform måste certifieras oberoende mot standarder som Board publicerar, den får inte kunna läsa de uppgifter den förmedlar, och den sparar samtyckesposter i minst sju år.

Reglerna överlåter standarden till Board. Bygg en inkommande väg nu, så att ett samtycke eller en återkallelse från en extern plattform hanteras exakt som en från ditt eget gränssnitt, och bind dig vid ett överföringsformat först när Board har publicerat ett. Registreringen öppnar runt 13 november 2026, så integrationen kommer realistiskt i gång i början av 2027.

Säkerhetsåtgärder och loggar (regel 6)

Minimilistan: kryptering, obfuskering, maskering eller tokenisering; åtkomstkontroll i de berörda systemen; ”insyn i åtkomsten till sådana personuppgifter genom lämpliga loggar, övervakning och granskning”; säkerhetskopior så att behandlingen kan fortsätta efter en incident; och lagring av ”sådana loggar och personuppgifter under en period av ett år”.

Loggkravet är där de flesta system brister. Infrastrukturloggar berättar inte vem som läste vilken kunds post från vilken tjänst, och det svaret behöver du ett år senare. Alltså: åtkomstloggning på applikationsnivå i varje lager med personuppgifter, skickad till en plats som tjänsterna inte kan ändra i, sparad i minst ett år. Börja tidigt; att rulla ut det över många tjänster tar längre tid än någon enskild funktion här.

Anmälan av incidenter (regel 7)

När du får kännedom om en incident ska du ”utan dröjsmål” informera varje berörd användare, via användarkontot eller en registrerad kontaktkanal: vad som hände, de sannolika konsekvenserna för dem, vad du gör, vad de kan göra och vem de ska kontakta. Board får en beskrivning utan dröjsmål och därefter, inom 72 timmar, en utförlig rapport om orsaker, begränsande åtgärder, eventuella slutsatser om vem som orsakade incidenten, korrigerande åtgärder och de meddelanden som skickats till användarna. Board kan medge längre tid efter skriftlig begäran.

I programvaran: ett sätt att räkna fram vilka som berörs (vilket hänger på åtkomstloggarna ovan), mallar skrivna i förväg, en aviseringsväg som inte går genom det drabbade systemet, och en körbok som anger vem som anmäler till Board.

Radering och lagring (regel 8)

Avsnitt 8(7) kräver radering när samtycket återkallas eller ändamålet inte längre tjänas, om inte en annan lag kräver lagring. Regel 8 lägger till två saker.

För det första anses ändamålet ha upphört efter tre år utan kontakt för tre klasser i Third Schedule: e-handelsaktörer med minst två crore (20 miljoner) registrerade användare i Indien, förmedlare av onlinespel med minst femtio lakh (5 miljoner) och förmedlare av sociala medier med minst två crore (20 miljoner). Kontoåtkomst och lagrade värdebevis är undantagna. Du måste varna användaren minst 48 timmar före raderingen, och en inloggning stoppar den. Det är en inaktivitetsräknare, en schemaläggare och ett aviseringsjobb. De tre åren räknas från den senaste kontakten eller från att reglerna trädde i kraft, beroende på vilket som inträffar senast. Ingen radering blir alltså aktuell på flera år, men spårningen måste vara rätt från början.

För det andra sätter regel 8(3) ett golv: personuppgifter, trafikdata och behandlingsloggar sparas i minst ett år från behandlingen. Regelns exempel är en beställning av en e-bok vars uppgifter måste finnas kvar efter att kontot raderats. ”Radera mitt konto” kan alltså inte betyda DELETE FROM users. Det betyder: stoppa behandlingen, flytta det som måste sparas till ett begränsat lager med ett lagringsdatum, och radera det när datumet har passerat. Varje tabell behöver en lagringsklass, och det gör även varje kopia i säkerhetskopior, datalagret och dina personuppgiftsbiträdens system.

Begäranden om rättigheter och kontaktuppgifter (regel 9 och 14)

Användare kan begära en sammanställning av sina uppgifter och behandlingen samt identiteten på varje fiduciary och processor du har delat dem med (avsnitt 11), begära rättelse, komplettering, uppdatering eller radering (avsnitt 12), och utse någon som agerar för dem vid dödsfall eller oförmåga (avsnitt 14). Regel 14 kräver att du publicerar hur man gör en begäran och vilken identifierare du behöver, och att du besvarar klagomål inom en publicerad tidsfrist på högst nittio dagar. Regel 9 kräver att kontaktuppgifterna till ditt dataskyddsombud (Data Protection Officer), eller till någon som kan svara, finns med i varje svar.

Att bygga: mottagning av begäranden i appen, identitetskontroll kopplad till kontot, ett ärendesystem som håller koll på nittiodagarsfristen, en export som hittar en användares uppgifter i alla tjänster, och ett delningsregister så att ”vem har ni delat dem med” blir en fråga till databasen i stället för en utredning.

Barn och personer med funktionsnedsättning (regel 10 till 12)

Enligt lagen är ett barn den som är under arton år. Innan du behandlar ett barns uppgifter behöver du ett verifierbart samtycke från en förälder, och regel 10 kräver en kontroll av att föräldern är en identifierbar vuxen. Kontrollen kan använda identitets- och åldersuppgifter som du redan har om en registrerad förälder, uppgifter som föräldern lämnar, eller ”en virtuell token kopplad till sådana uppgifter” från en auktoriserad aktör, vilket inkluderar en leverantör av Digital Locker-tjänster. MeitY:s DigiLocker publicerar API:er för förfrågare för organisationer som hämtar verifierade dokument; låt en jurist bekräfta vilka källor som uppfyller regeln i dina flöden.

Avsnitt 9(3) förbjuder spårning, beteendeövervakning och riktad reklam mot barn. För en konsumentapp är det ett SDK-problem, och det säkra förvalet är att stänga av analys- och annons-SDK:er för varje konto som är markerat som minderårigt, i stället för att försöka konfigurera dem så att de följer reglerna.

Regel 11 gäller förordnade förmyndare för personer med funktionsnedsättning: du kontrollerar att förmyndaren har utsetts av en domstol, en utsedd myndighet eller en lokal kommitté. Det är en dokumentuppladdning och en kö för manuell granskning. Enligt indiska advokatbyråer utfärdade MeitY i oktober 2026 en förordning med stöd av avsnitt 43 i lagen, Digital Personal Data Protection (Removal of Difficulties) Order, 2026 (S.O. 5458(E)), som rättar avsnitt 9(1) till att lyda ”ett barn eller en person med funktionsnedsättning”. Kravet på verifierbart samtycke omfattar nu uttryckligen uppgifter om en person med funktionsnedsättning såväl som ett barns. Ändringen beskrivs som redaktionell och lägger inte till något steg i det här flödet.

Regel 12 och Fourth Schedule undantar viss behandling från kravet på föräldrasamtycke och spårningsförbudet, bland annat hälso- och sjukvård, utbildningsinstitutioner (för utbildningsverksamhet och säkerhet), realtidsposition av säkerhetsskäl och kontroll av att en användare inte är ett barn. Ett edtechbolag bör inte utgå från att det räknas som en ”utbildningsinstitution”. Få det besvarat skriftligt.

Significant Data Fiduciaries (regel 13)

Om regeringen utser dig till Significant Data Fiduciary lägger regel 13 till en årlig konsekvensbedömning avseende dataskydd (Data Protection Impact Assessment) och revision med rapport till Board, en kontroll av att din algoritmiska programvara inte äventyrar användarnas rättigheter, och att personuppgifter som regeringen anger ska lagras i Indien. Avsnitt 10 i lagen lägger till ett dataskyddsombud baserat i Indien och en oberoende datarevisor. Samma förordning ersätter enligt uppgift ”audit” med ”data audit” i avsnitt 10(2)(c)(ii), vilket knyter den återkommande revisionen till den revisorns arbete. Datumet kan också flyttas: i januari 2026 rapporterade Business Standard att MeitY hade föreslagit att fristen för vissa bestämmelser, bland dem regel 13, skulle kortas från 18 till 12 månader. Per 10 oktober 2026 har vi inte hittat någon kungörelse som genomför den ändringen, så 13 maj 2027 gäller.

Vad det kostar att göra fel

Schedule till lagen anger maximala sanktionsavgifter: upp till 250 crore (2,5 miljarder) rupier för att inte vidta rimliga säkerhetsåtgärder, upp till 200 crore för att inte anmäla en incident, upp till 200 crore för brott mot skyldigheterna kring barns uppgifter, upp till 150 crore för en Significant Data Fiduciarys ytterligare skyldigheter, och upp till 50 crore för brott mot någon annan bestämmelse.

En plan på sju månader

Oktober 2026: inventera. Lista varje lager och pipeline som innehåller indiska användares personuppgifter, inklusive säkerhetskopior, datalagret, loggar och personuppgiftsbiträden. Koppla varje fält till ett ändamål. Markera användare som är barn, kontrollera tröskelvärdena i Third Schedule och få en jurists syn på tillämpningsområde och undantag.

November 2026: designa. Innehållsmodell och versionshantering för informationen, schema för samtyckesliggaren, lagringsklasser per tabell, flöde för begäranden om rättigheter. Börja med åtkomstloggningen. Efter omkring 13 november: håll koll på Board för registrerade Consent Managers och interoperabilitetsstandarden.

December 2026 till januari 2027: information och samtycke. Driftsätt samtyckestjänsten, med återkallelsehändelser som sprids ut till personuppgiftsbiträdena. Översätt informationstexterna.

Februari 2027: lagring och radering. Ett begränsat lagringslager, raderingsjobb i de primära lagren och hos personuppgiftsbiträdena, och inaktivitetsräknaren om du tillhör en klass i Third Schedule. Ändra biträdesavtalen så att de täcker säkerhetsåtgärder och lagring i ett år.

Mars 2027: rättigheter och incidenter. Mottagning av begäranden, verifiering, ärendesystemet med nittiodagarsfristen, export över alla tjänster, delningsregister. Körbok för incidenter, mallar och en oberoende aviseringsväg, sedan en skrivbordsövning.

April 2027: barn och befintliga användare. Åldersspärr, verifiering av föräldrar, SDK-avstängning för minderåriga, granskning av förmyndare. Skicka informationen enligt avsnitt 5(2) till befintliga användare. Integrera med Consent Managers om standarden har kommit.

Början av maj 2027: testa och frys. Återkalla ett samtycke och bekräfta att marknadsföringsplattformen slutade. Begär en radering och bekräfta att kopian i datalagret flyttades till lagringslagret. Samla ihop underlaget och sluta ändra saker veckan före 13 maj.

Planen förutsätter tre eller fyra parallella spår. I äldre eller odokumenterade system tar enbart inventeringen längre tid än en månad.

Hur det här hänger ihop

Om du byggde för dataskyddsförordningen (GDPR) går en stor del av grundarbetet att återanvända, och vår tekniska guide till GDPR går igenom mönstren för samtycke och radering. Skillnaderna som svider är den specificerade informationen, golvet på ett års lagring och verifierbart föräldrasamtycke upp till arton år. För en annan asiatisk marknad med en egen regim, se Indonesia PSE registration.

Vi bygger in samtyckestjänster, lagrings- och raderingsjobb, åtkomstloggning och arbetsflöden för begäranden om rättigheter i befintliga produkter, och vi förstärker ditt team med utvecklare genom konsultförstärkning när planen kräver fler händer än du har. Vi är ingenjörer, inte jurister: tillämpningsområde och formuleringar hör hemma hos din jurist, och vi bygger efter deras svar. Skriv till office@c9group.dev.