Indias DPDP Rules: utviklingsarbeidet som må være ferdig innen mai 2027

India kunngjorde Digital Personal Data Protection Rules, 2025 den 13. november 2025, som G.S.R. 846(E). De fleste reglene som berører produktet ditt, er ennå ikke trådt i kraft. Regel 1(4) sier at reglene 3, 5 til 16, 22 og 23 «trer i kraft atten måneder etter datoen for kunngjøringen i denne lovtidende (Gazette)». Teller du atten måneder, havner du på 13. mai 2027, litt over sju måneder fra i dag.

De omfatter personvernerklæringer, sikkerhet, varsling om brudd, oppbevaring og sletting, barns data og forespørsler om rettigheter. Regel 4, som lar samtykkeforvaltere (Consent Managers) registrere seg hos Data Protection Board, kommer tidligere: ett år etter kunngjøringen, altså rundt 13. november 2026. Myndighetenes kunngjøring kaller det en trinnvis tidslinje over 18 måneder.

Dette er skrevet for teknologidirektører og produktledere i indiske forbrukerapper, fintech-, edtech- og netthandelsselskaper, og i utenlandske selskaper med indiske brukere. Loven når behandling utenfor India når den skjer «i forbindelse med enhver aktivitet knyttet til å tilby varer eller tjenester til registrerte (Data Principals) innenfor Indias territorium» (section 3(b)). Det som følger, er programvaren du må bygge eller endre. Det er ikke en juridisk gapanalyse: om du er omfattet, hvilke unntak som gjelder og hvordan formålene dine er formulert, er spørsmål for juristene deres.

Hvem som faktisk har utviklingsarbeid

Ligger alle kundedataene dine i én standard SaaS-plattform, kommer mye av rørleggerarbeidet (kryptering, tilgangslogger, slettejobber) fra leverandørens veikart. Ditt arbeid er erklæringer, konfigurasjon og kontrakter. Les de kontraktene: regel 6(1)(f) krever at sikkerhetstiltak skrives inn i dem, og et eksempel til regel 8 gjør deg ansvarlig for at skyleverandøren din oppbevarer data og logger i det påkrevde året.

Det tunge arbeidet faller på selskaper som drifter egne apper og databaser, mater et datavarehus fra et dusin løyper og leverer tredjeparts-SDK-er i mobilklienten. Det er det meste av det indiske forbrukerinternettet.

Hva hver regel krever av programvaren din

Personvernerklæring (regel 3)

Erklæringen må være «forståelig uavhengig av annen informasjon» du publiserer. Den skal som et minimum gi «en spesifisert beskrivelse av slike personopplysninger», det angitte formålet og en konkret beskrivelse av varene, tjenestene eller bruken behandlingen muliggjør. Den må også si hvordan man trekker tilbake samtykke, utøver rettigheter og klager til Board.

I praksis:

• Generer erklæringer fra en dataoversikt. Felt for felt, koblet til formål. «Vi kan samle inn opplysninger som» er ikke spesifisert.
• Versjoner hver erklæring. Hver samtykkepost må peke på den nøyaktige teksten brukeren så.
• Planlegg for språk. Section 6(3) i loven krever muligheten til å lese en samtykkeforespørsel på engelsk eller et hvilket som helst språk i den åttende listen (Eighth Schedule) til grunnloven. Hold innholdet i erklæringen som oversettbare tekststrenger, ikke en PDF.
• Dekk eksisterende brukere. Section 5(2) krever en erklæring, «så snart det er rimelig praktisk mulig», til personer som samtykket før loven trådte i kraft. Det er en kampanje til hele brukerbasen din.

Samtykke, tilbaketrekking og samtykkeforvaltere

Samtykke etter section 6 må være spesifikt og begrenset til de dataene formålet trenger. Section 6(10) legger bevisbyrden på deg: i en tvist viser du at erklæringen ble gitt og samtykket innhentet. Den setningen er grunnen til at du trenger en samtykkelogg og ikke en boolsk kolonne.

En brukbar logg registrerer, per bruker og formål: versjon av erklæringen, tidsstempel, kanal (web, app, samtykkeforvalter) og handling (gitt eller trukket tilbake). Bare tillegg, aldri endring.

Tilbaketrekking må være like enkelt som å gi samtykke (regel 3(c)(i), section 6(4)). Var samtykket ett trykk under registreringen, kan ikke tilbaketrekkingen være en e-post til kundeservice. Den må også spres videre. Section 6(6) krever at du slutter å behandle, og får databehandlerne dine til å slutte, innen rimelig tid. Samtykketjenesten publiserer derfor tilbaketrekkingshendelser til hvert system og hver leverandør som handler på det formålet: CRM, markedsføringsplattform, analyseløype.

En samtykkeforvalter er et registrert felles kontaktpunkt der en bruker kan «gi, administrere, gjennomgå eller trekke tilbake sitt samtykke» (section 6(7)). Etter den første listen (First Schedule) må den være et selskap registrert i India med en nettoformue på minst to crore rupier (1 crore er 10 millioner), plattformen må være uavhengig sertifisert mot standarder Board publiserer, den må ikke kunne lese dataene den ruter, og den oppbevarer samtykkeposter i minst sju år.

Reglene overlater den standarden til Board. Bygg en innkommende løype nå, slik at et samtykke eller en tilbaketrekking som kommer fra en ekstern plattform, behandles nøyaktig som en fra ditt eget brukergrensesnitt, og forplikt deg til et overføringsformat først når Board publiserer et. Registreringen åpner rundt 13. november 2026, så integrasjonen starter realistisk sett tidlig i 2027.

Sikkerhetstiltak og logger (regel 6)

Minimumslisten: kryptering, tilsløring, maskering eller tokenisering; tilgangskontroll på systemene som er involvert; «innsyn i tilgangen til slike personopplysninger gjennom egnede logger, overvåking og gjennomgang»; sikkerhetskopier slik at behandlingen kan fortsette etter en hendelse; og oppbevaring av «slike logger og personopplysninger i en periode på ett år».

Loggkravet er der de fleste systemer kommer til kort. Infrastrukturlogger forteller deg ikke hvem som leste hvilken kundes post fra hvilken tjeneste, og det svaret trenger du et år senere. Altså: tilgangslogging på applikasjonsnivå for hvert lager av personopplysninger, sendt et sted tjenestene ikke kan endre, og oppbevart i minst ett år. Start tidlig; å rulle det ut på tvers av mange tjenester tar lengre tid enn noen enkeltfunksjon her.

Varsling om brudd (regel 7)

Når du blir kjent med et brudd, varsler du hver berørte bruker «uten opphold», gjennom brukerkontoen eller en registrert kontaktkanal: hva som skjedde, de sannsynlige konsekvensene for dem, hva du gjør, hva de kan gjøre, og hvem de kan kontakte. Board får en beskrivelse uten opphold, og deretter innen 72 timer en detaljert rapport om årsaker, avbøtende tiltak, eventuelle funn om hvem som forårsaket det, utbedringstiltak og varslene som er sendt til brukerne. Board kan tillate lengre tid etter skriftlig anmodning.

I programvare: en måte å beregne hvem som er berørt (som avhenger av tilgangsloggene over), maler skrevet på forhånd, en varslingsvei som ikke går gjennom systemet som er rammet, og en driftsinstruks som navngir hvem som melder til Board.

Sletting og oppbevaring (regel 8)

Section 8(7) krever sletting når samtykket trekkes tilbake eller formålet ikke lenger tjenes, med mindre annen lovgivning krever oppbevaring. Regel 8 legger til to ting.

For det første står tre klasser i den tredje listen (Third Schedule) overfor et antatt opphør av formålet etter tre år uten kontakt: netthandelsaktører med minst to crore registrerte brukere i India, mellomledd for nettspill med minst femti lakh (5 millioner) og mellomledd for sosiale medier med minst to crore. Kontotilgang og tokener med lagret verdi er unntatt. Du må varsle brukeren minst 48 timer før sletting, og en innlogging avbryter den. Det er en sporing av inaktivitet, en planlegger og en varslingsjobb. De tre årene løper fra siste kontakt eller fra ikrafttredelsen av reglene, det som kommer sist, så ingen sletting forfaller på flere år, men sporingen må være riktig fra start.

For det andre setter regel 8(3) et gulv: personopplysninger, trafikkdata og behandlingslogger oppbevares i minst ett år fra behandlingen. Regelens eksempel er en e-bokbestilling der detaljene må overleve at kontoen slettes. «Slett kontoen min» kan altså ikke bety DELETE FROM users. Det betyr: stopp behandlingen, flytt det som må beholdes, til et begrenset lager med en oppbevaringsdato, og slett det når datoen er passert. Hver tabell trenger en oppbevaringsklasse, og det samme gjør hver kopi i sikkerhetskopier, datavarehuset og databehandlernes systemer.

Forespørsler om rettigheter og kontaktopplysninger (regel 9 og 14)

Brukere kan be om en oppsummering av dataene sine og behandlingen, og identiteten til hver behandlingsansvarlig og databehandler du har delt dem med (section 11), be om retting, utfylling, oppdatering eller sletting (section 12), og utpeke noen som kan handle på deres vegne ved dødsfall eller manglende handleevne (section 14). Regel 14 krever at du publiserer hvordan man fremmer en forespørsel, og hvilken identifikator du trenger, og at du besvarer klager innen en publisert frist på høyst nitti dager. Regel 9 krever kontaktopplysningene til personvernombudet ditt (Data Protection Officer), eller til noen som kan svare, i hvert svar.

Det som må bygges: mottak av forespørsler i appen, identitetsverifisering knyttet til kontoen, en saksoppfølging som holder styr på fristen på nitti dager, en eksport som finner en brukers data på tvers av tjenester, og et delingsregister slik at «hvem har dere delt det med» er en spørring og ikke en etterforskning.

Barn og personer med funksjonsnedsettelse (regel 10 til 12)

Etter loven er et barn alle under atten år. Før du behandler et barns data, trenger du verifiserbart samtykke fra en forelder, og regel 10 krever at du kontrollerer at forelderen er en identifiserbar voksen. Kontrollen kan bruke identitets- og aldersopplysninger du allerede har for en registrert forelder, opplysninger forelderen oppgir, eller «et virtuelt token koblet til slike opplysninger» fra en autorisert enhet, som omfatter en tilbyder av Digital Locker-tjenester. MeitYs DigiLocker publiserer API-er for forespørrere for organisasjoner som henter verifiserte dokumenter; få juristene til å bekrefte hvilke kilder som oppfyller regelen for flytene dine.

Section 9(3) forbyr sporing, atferdsovervåking og målrettet annonsering rettet mot barn. For en forbrukerapp er det et SDK-problem, og det trygge standardvalget er å slå av analyse- og annonse-SDK-er for alle kontoer som er merket som mindreårige, i stedet for å konfigurere dem til å etterleve reglene.

Regel 11 gjelder verger for personer med funksjonsnedsettelse: du kontrollerer at vergen er oppnevnt av en domstol, en utpekt myndighet eller en lokal komité. Det er en dokumentopplasting og en kø for manuell gjennomgang.

Regel 12 og den fjerde listen (Fourth Schedule) unntar noe behandling fra kravet om foreldresamtykke og forbudet mot sporing, blant annet helsetjenester, utdanningsinstitusjoner (for undervisning og sikkerhet), posisjon i sanntid av sikkerhetshensyn og bekreftelse av at en bruker ikke er et barn. Et edtech-selskap bør ikke gå ut fra at det regnes som en «utdanningsinstitusjon». Få det besvart skriftlig.

Vesentlige behandlingsansvarlige (regel 13)

Utpeker myndighetene deg som Significant Data Fiduciary, legger regel 13 til en årlig vurdering av personvernkonsekvenser (Data Protection Impact Assessment) og revisjon med rapport til Board, aktsomhetsvurdering av at den algoritmiske programvaren din ikke setter brukernes rettigheter i fare, og at personopplysninger myndighetene angir, holdes i India. Section 10 i loven legger til et personvernombud basert i India og en uavhengig datarevisor.

Hva det koster å gjøre det feil

Listen (Schedule) til loven fastsetter maksimale sanksjoner: opptil 250 crore rupier for ikke å ha rimelige sikkerhetstiltak, opptil 200 crore for ikke å varsle om et brudd, opptil 200 crore for brudd på pliktene knyttet til barns data, opptil 150 crore for tilleggspliktene til en Significant Data Fiduciary, og opptil 50 crore for brudd på andre bestemmelser.

En plan over sju måneder

Oktober 2026: kartlegging. List opp hvert lager og hver løype som inneholder personopplysninger om indiske brukere, inkludert sikkerhetskopier, datavarehuset, logger og databehandlere. Koble hvert felt til et formål. Merk brukere som er barn, sjekk tersklene i den tredje listen, og få juristenes syn på virkeområde og unntak.

November 2026: design. Innholdsmodell og versjonering for erklæringer, skjema for samtykkeloggen, oppbevaringsklasser per tabell, flyt for forespørsler om rettigheter. Start tilgangsloggingen. Etter rundt 13. november, følg med på Board for registrerte samtykkeforvaltere og standarden for interoperabilitet.

Desember 2026 til januar 2027: erklæringer og samtykke. Lever samtykketjenesten, med tilbaketrekkingshendelser spredt ut til databehandlerne. Oversett erklæringene.

Februar 2027: oppbevaring og sletting. Begrenset oppbevaringslager, slettejobber på tvers av primærlagre og databehandlere, og sporingen av inaktivitet hvis du hører til en klasse i den tredje listen. Endre databehandleravtalene for sikkerhetstiltak og oppbevaringen i ett år.

Mars 2027: rettigheter og brudd. Mottak av forespørsler, verifisering, saksoppfølging med frist på nitti dager, eksport på tvers av tjenester, delingsregister. Driftsinstruks for brudd, maler og en uavhengig varslingsvei, og deretter én skrivebordsøvelse.

April 2027: barn og eksisterende brukere. Aldersgrense, verifisering av foreldre, SDK-brytere for mindreårige, gjennomgang av verger. Send erklæringen etter section 5(2) til eksisterende brukere. Integrer med samtykkeforvaltere hvis standarden er kommet.

Begynnelsen av mai 2027: test og frys. Trekk tilbake et samtykke og bekreft at markedsføringsplattformen stoppet. Be om en sletting og bekreft at kopien i datavarehuset gikk til oppbevaring. Sett sammen dokumentasjonen, og slutt å endre ting uken før 13. mai.

Dette forutsetter tre eller fire parallelle arbeidsstrømmer. På eldre eller udokumenterte systemer tar kartleggingen alene mer enn en måned.

Hvor dette passer inn

Har du bygget for GDPR, kan en god del av rørleggerarbeidet tas med videre, og vår utviklerguide til GDPR dekker mønstrene for samtykke og sletting. Forskjellene som biter, er den spesifiserte erklæringen, gulvet for oppbevaring på ett år og verifiserbart foreldresamtykke opp til atten år. For et annet asiatisk marked med eget regime, se registrering som PSE i Indonesia.

Vi bygger samtykketjenester, oppbevarings- og slettejobber, tilgangslogging og arbeidsflyter for forespørsler om rettigheter inn i eksisterende produkter, og vi tilfører utviklere til teamet ditt gjennom teamforsterkning når planen trenger flere hender enn dere har. Vi er ingeniører, ikke jurister: virkeområde og formuleringer hører hjemme hos juristene deres, og vi bygger etter svaret de gir. Skriv til office@c9group.dev.