DPDP in practice

Ten phases, in an order where each one feeds the next.

Most DPDP programmes stall because they start with the most visible piece, the privacy notice, and then discover they do not know what data they hold. This roadmap runs in dependency order. Every phase ends with something you can hand to a reviewer.

Back to DPDP services

01 · Why order matters

Start with what you hold, not with what you publish

Notices, rights and erasure all read from the data map.

Notice first

  • Purposes guessed from marketing copy
  • Data items missed, so the notice is not itemised
  • Rewritten once the map arrives

Map first

  • Purposes taken from real systems
  • Each notice line traces to a data set
  • Rights, retention and vendors reuse the same list

Rule 3 wants an itemised list of personal data in each notice. You cannot itemise what you have not inventoried.

02 · The ten phases

The programme, phase by phase

What to do, what to produce, what good looks like, and what to avoid.

  1. Data map

    Find every place personal data enters, rests and leaves.

    What happens
    • Interview system owners
    • List data items, sources, purposes and recipients
    • Note which data concerns children
    You get
    • A processing record per purpose
    • A system and vendor inventory
    Good practice
    • Every row has an owner
    • Purposes are concrete enough to quote in a notice
    Watch for
    • Mapping only the production database
    • Leaving out spreadsheets and support inboxes
  2. Roles

    Decide where you are a fiduciary and where a processor.

    What happens
    • Classify each flow by who decides purpose and means
    • Check whether you may be a significant data fiduciary
    You get
    • A role register per flow
    • A short note on the significant data fiduciary question
    Good practice
    • Roles agreed with legal counsel
    • Mixed roles recorded per product, not per company
    Watch for
    • Assuming a SaaS vendor is always only a processor
  3. Notices and consent

    Write notices that stand alone and capture consent you can prove.

    What happens
    • Draft itemised notices per purpose
    • Build consent and withdrawal into the product
    • Plan notices for people who consented before the Act
    You get
    • Notice set, with language versions
    • Consent records with timestamps and notice version
    Good practice
    • Withdrawal is as easy as giving consent
    • Each consent can be tied to the notice shown
    Watch for
    • Bundling unrelated purposes into one tick box
  4. Rights workflow

    Answer access, correction, erasure and nomination requests on time.

    What happens
    • Publish how to make a request and what identifier is needed
    • Set intake, identity checks and routing
    You get
    • A request procedure and log
    • A published grievance response period
    Good practice
    • Requests reach systems through the data map
    • Replies carry the contact point
    Watch for
    • Running requests from a shared inbox with no log
  5. Vendor contracts

    Bind every processor to security, breach notice and erasure.

    What happens
    • List processors from the data map
    • Add clauses for safeguards, breach notice, erasure and log retention
    You get
    • A processor register
    • Signed amendments or a remediation list
    Good practice
    • Breach notice time in the contract leaves room for your own reporting
    Watch for
    • Relying on the vendor's standard terms unread
  6. Safeguards

    Meet rule 6's minimum measures and record how.

    What happens
    • Check encryption or masking, access control, logging, backups
    • Set log retention to at least one year
    You get
    • A safeguards matrix with control owners
    • Gap tickets
    Good practice
    • Existing ISO 27001 or SOC 2 evidence reused where it fits
    Watch for
    • Assuming a certificate settles the duty
  7. Breach plan

    Be ready to tell the Board and every affected person.

    What happens
    • Write the decision path from alert to notices
    • Prepare both notice templates
    • Run a tabletop exercise
    You get
    • Breach procedure, templates and exercise record
    Good practice
    • The 72-hour report has a named author and a draft ready
    Watch for
    • A plan that only covers CERT-In reporting
  8. Retention

    Set when each data set goes, and make it go.

    What happens
    • Set periods per purpose with legal holds noted
    • Automate deletion where possible
    You get
    • A retention schedule
    • Erasure jobs and their logs
    Good practice
    • Each period cites a reason: purpose, law or rule
    Watch for
    • One period for everything
  9. Governance

    Give the programme an owner and a rhythm.

    What happens
    • Name the contact point (or DPO if significant)
    • Set a review cycle and a reporting line to leadership
    You get
    • Privacy policy set, RACI, review calendar
    • Training records
    Good practice
    • Leadership sees privacy metrics on a schedule
    Watch for
    • A privacy owner with no authority over engineering
  10. Evidence

    Gather proof that each duty runs, not just that it is written.

    What happens
    • Collect samples: consents, requests, erasures, access reviews
    • Test a few end to end
    You get
    • An evidence index mapped to each duty
    Good practice
    • Evidence is dated, sourced and owned
    Watch for
    • Screenshots with no date or system name

03 · What you hold

What exists when the roadmap is done

One table, so nothing is only in someone's head.

PhaseMain outputUsual ownerRefresh when
Data mapProcessing record and inventoryPrivacy lead with system ownersNew system, vendor or purpose
RolesRole registerLegal counselNew product or contract model
Notices and consentNotice set and consent recordsProduct and legalPurpose or data items change
Rights workflowProcedure, request log, published periodSupport or privacy deskVolume or channel changes
Vendor contractsProcessor register and clausesProcurementEach new processor
SafeguardsSafeguards matrixSecurity leadAfter audits and incidents
Breach planProcedure, templates, exercise recordSecurity and legalAfter each exercise or incident
RetentionSchedule and erasure logsData ownersLaw or purpose changes
GovernancePolicy set, RACI, calendarExecutive sponsorYearly
EvidenceEvidence indexPrivacy leadEach review cycle

04 · Working back

Working back from the dates you know

The calendar is set by rule 1. The roadmap should be set by it too.

Most company duties in the Rules start eighteen months after the Rules were published in November 2025. Phases 3 to 8 build the things those rules test, so they need to be running before that date with some history behind them, not finishing on it.

  • If you plan to receive consents through a consent manager, registration opens one year after publication. Talk to providers before you design consent capture.
  • Notices for people who consented before the Act are owed as soon as reasonably practicable after commencement. Plan the send early.
  • Anything that needs engineering, such as withdrawal flows, erasure jobs and log retention, should be scheduled first; contracts and policies move faster.

05 · Who runs it

The people a roadmap needs

Six roles, often fewer people.

  1. Executive sponsorClears budget and settles disputes between teams.
  2. Privacy leadOwns the map, the plan and the evidence index.
  3. EngineeringBuilds consent, withdrawal, erasure and logging.
  4. SecurityOwns safeguards and the breach plan.
  5. Legal counselSettles roles, notices, contracts and retention conflicts.
  6. Support deskRuns requests and grievances day to day.

06 · Where it slips

Where DPDP roadmaps usually slip

Each of these has a fix inside the phases above.

  • Treating it as a document project. Policies arrive on time; erasure jobs and withdrawal flows do not.
  • Skipping the processors. Your duties cover what vendors do for you. A vendor with no erasure clause stalls phase 8.
  • One owner for everything. A privacy lead without engineering time cannot ship phases 3, 4 or 8.
  • No evidence until the end. Evidence collected late is thin. Start the index in phase 1.
  • Ignoring the significant data fiduciary question. If you might be notified, the yearly assessment and audit change the plan.

Sources: the Digital Personal Data Protection Act, 2023 (sections 5, 6, 8, 10, 11 to 13); the Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), rules 1, 3, 4, 6 to 9 and 14.

Questions about the roadmap

Can the phases run in parallel?

Some can, once the data map exists.

After phases 1 and 2, notices, vendor contracts and safeguards can move at the same time with different owners. Retention and the rights workflow lean on the map and on engineering, so they rarely finish first.

We already hold ISO 27001. Which phases shrink?

Mostly safeguards and parts of governance and evidence.

An ISMS gives you access control, logging, backups, supplier management and an audit rhythm. It does not give you notices, consent, rights handling or erasure tied to purpose, so phases 3, 4 and 8 stay full size.

How long does each phase take?

It depends on how many systems and vendors you have.

We set durations after the data map, when the number of systems, purposes and processors is known. We do not publish a standard figure.

Is there a certificate at the end?

No. There is no DPDP certificate.

The Act has no certification scheme. What you have at the end is a working programme and an evidence file that shows the Board, customers and auditors how each duty is met.

Put the phases in the right order from day one.

A DPDP readiness assessment turns this roadmap into a plan for your systems and owners. Counsel should confirm how the Act and the Rules apply to your contracts and sector.