SWARNA DPDPHQ PRODUCT
Menu

DPDP/HQ · LOCAL INDEX

Go directly to the work.

Product claims and buying decisions · SW050

Privacy workflow software and a registered Consent Manager are different roles

Distinguish privacy workflow tools from the DPDP Act’s registered Consent Manager role, including the separate registration and substantive timelines.

SWARN is in development. Product workflows described here are design and evaluation guidance; availability depends on the published product status and agreed scope.

Product truth represented by a sculptural gold and plum composition.

Software can help a business record choices, route requests or maintain evidence without being a registered Consent Manager under the DPDP Act. The statutory role has a specific definition and registration framework.

That distinction affects product language, procurement questions and responsibility. A feature called “consent management” does not by itself establish the provider’s legal status.

SWARN is in development. This article explains the distinction and does not claim that SWARN is registered with the Data Protection Board or currently provides any particular workflow.

What the statutory term means

Section 2(g) of the DPDP Act defines a Consent Manager as a person registered with the Board who acts as a single point of contact for a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform.

The registration element is central. A cookie tool, preference database or privacy case-management application does not become a statutory Consent Manager merely by using similar words.

The definition also concerns a role serving the individual in the specified consent process. A business’s internal record of its own customer choices is a different function, even if the underlying software offers useful consent features.

Classify the actual service and legal relationship rather than relying on a product category label.

Read the two commencement stages carefully

As of 22 October 2026, the definition is in force, while the Consent Manager registration phase is scheduled for 13 November 2026. The commencement notification places section 6(9) and section 27(1)(d) in that earlier phase.

The broader substantive provisions, including section 6(7) and 6(8), are scheduled for 13 May 2027. The final Rules, read with their corrigendum, bring rule 4 into force on 13 November 2026, separately from most business obligations.

These dates should not be collapsed into a claim that the entire consent regime is already operative. Nor should the existence of final rules be described as a merely draft framework.

Any claim that a named organisation is registered should be checked against current authoritative registration evidence. This article makes no assertion about a current registered-provider list.

Registration involves more than a feature checklist

Rule 4 and the First Schedule set conditions for registration and obligations for the role. The applicant must be a company incorporated in India with at least ₹2 crore net worth, alongside the prescribed capacity and governance requirements.

Net worth is not the same as paid-up share capital. These conditions are also not universal requirements for every shop, software company or Data Fiduciary using a consent workflow.

The Schedule addresses matters including platform assurance, records, conduct, conflicts and security. It also requires the contents of personal data shared through the specified process to remain unreadable to the Consent Manager. An architecture should be assessed against the actual provisions and applicable standards rather than declared compliant from a marketing diagram.

The Schedule’s minimum seven-year retention requirement concerns prescribed Consent Manager records, with longer retention under the stated agreement or legal conditions. It should not be copied into a blanket rule for every business’s entire customer database.

What ordinary workflow software can contribute

A hypothetical retailer may need a clear preference screen, versioned notices, a withdrawal queue and evidence that its campaign system received an instruction. A software provider could help implement parts of that process.

The legal role of the provider still depends on the actual processing. The Act’s definitions in sections 2(i) and 2(k) distinguish a Data Fiduciary that determines purpose and means from a Data Processor acting on its behalf. A provider may perform different roles for different activities.

A contract and a useful interface do not resolve every responsibility. The retailer still needs to identify its purposes, evaluate its processing and operate the workflow appropriately. Future accountability under the Act should be assessed against the relevant provisions and commencement.

This is why procurement should ask both what the software does and what legal role the provider claims.

Questions that keep the distinction clear

Before relying on a provider’s description, ask:

  • Is “consent management” a feature description or a claim to the statutory role?
  • If registration is claimed, what current Board evidence supports it?
  • Which entity provides the service and which processing role does it perform?
  • Which functions are available, in pilot or still planned?
  • How are responsibilities, data access and operating limits documented?
  • Are Consent Manager-specific conditions being incorrectly presented as universal business duties?

A privacy tool can be useful without claiming a status it does not hold. Precise language lets businesses assess the service on its actual capabilities while keeping the statutory Consent Manager role tied to its legal definition and verified registration.

Separate software capability from statutory status

Separate software capability from statutory status. A useful workflow capability and a registered statutory role are separate matters that require separate evidence.
A useful workflow capability and a registered statutory role are separate matters that require separate evidence. Open full-size diagram
Text version of the diagram
  1. Workflow software: Records, routing and integrations within stated scope
  2. Statutory Consent Manager: Defined role requiring Board registration
  3. Status evidence: Verify the entity and authoritative registration
  4. Phased commencement: Registration and substantive provisions differ
  5. Procurement assessment: Evaluate capability, role and responsibility separately
  • Workflow software → Procurement assessment
  • Statutory Consent Manager → Status evidence
  • Status evidence → Procurement assessment
  • Phased commencement → Procurement assessment

Sources and reading context

These references support the original 22 October 2026 research. Source links and the date above make the scope of this article explicit.

  1. Digital Personal Data Protection Act, 2023 · Sections 2(g), 2(i)-(k), 6(7)-(10) and 8

    Supports statutory roles and responsibility distinctions

  2. Commencement notification for provisions of the DPDP Act · Sections 6(9), 27(1)(d), and the eighteen-month substantive phase

    Supports the separate future commencement dates

  3. Digital Personal Data Protection Rules, 2025 · Rules 1(3) and 4; First Schedule, Parts A and B

    Supports registration conditions and role-specific obligations

  4. Corrigenda to the Digital Personal Data Protection Rules, 2025 · Corrected publication wording

    Supports reading the final Rules with corrections