DPDPA Glossary 2023: Every Key Term Defined for Engineering and Legal Teams

Key Takeaways

• Misidentifying your compliance role — Data Fiduciary vs. Data Processor — changes your entire liability stack. Engineers who build internal tooling for a hospital are likely building for a Data Fiduciary; engineers who build the cloud storage platform the hospital uses may be a Data Processor.
• DPDPA has no "sensitive personal data" category. The 2019 PDP Bill had one; the enacted 2023 Act removed it entirely. Section 9 applies to children under 18 only.
• A "Consent Manager" is a regulated intermediary registered with the Data Protection Board — not a feature flag, cookie banner, or consent modal in your app.
• Cross-border transfers operate under a negative-list model (Section 16): permitted by default, restricted only for countries specifically notified by the Central Government.
• The Data Protection Board of India is both an adjudicatory body and an inquiry authority: it acts on breach intimations, Data Principal complaints, Government references and court directions (Section 27(1)). Its penalty ceilings in the Schedule apply per breach of a provision, not per individual affected.
• Every definition in this glossary is sourced directly from the DPDPA 2023 gazette text or DPDP Rules 2025. Where a concept has no statutory definition, that fact is stated explicitly.

Table of Contents

1. How to Use This Glossary
2. Entity Definitions: Who Is Who?
3. Data Definitions: What Is Covered?
4. Legal Grounds and Obligations
5. Technical and Operational Terms
6. Rights and Duties
7. Cross-Cutting Compliance Concepts
8. FAQ: Glossary Misconceptions

How to Use This Glossary

Data Fiduciary — Any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data (Section 2(i)).



Data Principal — The individual to whom the personal data relates (Section 2(j)).



Data Processor — Any person who processes personal data on behalf of a Data Fiduciary (Section 2(k)).



Data Protection Board of India (Board) — The adjudicatory body established under Section 18 to inquire into contraventions and impose penalties (Section 2(c)).



Significant Data Fiduciary (SDF) — A Data Fiduciary or class of Data Fiduciaries notified by the Central Government under Section 10(1) on the basis of volume, sensitivity, and risk criteria (Section 2(z)).



Consent Manager — A Board-registered intermediary that provides a single-point consent management platform for Data Principals (Section 2(g)).



Technical and Organisational Measures (TOMs) — Security and governance controls required by Section 8(4) (technical and organisational measures) and Section 8(5) (reasonable security safeguards), with Rule 6 of the DPDP Rules 2025 setting the minimum safeguards.

Each term below follows a three-part format:

1. Statutory definition (verbatim or paraphrased with section reference)
2. Plain-English translation — what it means operationally
3. Engineering implication — what your code, infra, or process must do

Entity Definitions: Who Is Who?

1. Data Principal

Statutory definition (Section 2(j)):

"the individual to whom the personal data relates and where such individual is—(i) a child, includes the parents or lawful guardian of such a child; (ii) a person with disability, includes her lawful guardian, acting on her behalf"

Plain-English translation: The person the data is about. Not the person who gave the data (those can differ), but the human being who is identifiable from it. Where a child or person with a disability is the subject, their parent or guardian is treated as the Data Principal for consent and rights purposes.

Engineering implication: Your consent record schema must link to the Data Principal — not the session or account. For child users, the schema needs a guardian_id field with its own verification and consent grant. Rights requests (access, erasure) come from the Data Principal or their authorised guardian, not necessarily from the account holder.

2. Data Fiduciary

Statutory definition (Section 2(i)):

"any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data"

Plain-English translation: The organisation that decides why personal data is collected and how it is used. If you are building a product that processes user data and you choose what to collect and what to do with it, you are the Data Fiduciary. Regulatory liability and the full obligation stack sit here.

Engineering implication: Your privacy notice, consent flows, Data Processing Agreements, breach notification obligations, and DSR portal are all Fiduciary responsibilities. If you use a third-party analytics SDK, payment processor, or cloud storage vendor to handle personal data, you (the Fiduciary) remain accountable to the Board — the vendor is your Data Processor.

3. Data Processor

Statutory definition (Section 2(k)):

"any person who processes personal data on behalf of a Data Fiduciary"

Plain-English translation: Any vendor, contractor, or service that handles personal data under your instructions. The Processor doesn't decide what data to collect or why — it just executes the Fiduciary's instructions. Cloud storage providers, SaaS analytics platforms, payment gateways, and offshore development teams that access user data are all typically Processors.

Engineering implication: Section 8(2) requires a valid contract (Data Processing Agreement) before engaging any Processor. Section 8(5) extends the Fiduciary's security obligations to "any processing undertaken by it or on its behalf by a Data Processor" — a Processor-caused breach is your regulatory liability. DPAs must include the reasonable-security-safeguards provision that Rule 6(1)(f) of the DPDP Rules 2025 requires in Fiduciary–Processor contracts, plus breach back-notification timelines, and Data Principal rights cooperation requirements.

4. Significant Data Fiduciary (SDF)

Statutory definition (Section 10(1)):

"The Central Government may notify any Data Fiduciary or class of Data Fiduciaries as Significant Data Fiduciary, on the basis of an assessment of such relevant factors as it may determine, including—(a) the volume and sensitivity of personal data processed; (b) risk to the rights of Data Principal; (c) potential impact on the sovereignty and integrity of India; (d) risk to electoral democracy; (e) security of the State; and (f) public order."

Plain-English translation: An elevated-risk tier of Data Fiduciary designated by government notification. No organisation self-selects as an SDF — the Government designates it. Under Section 10(2), an SDF must appoint a DPO based in India, appoint an independent data auditor, and carry out periodic DPIAs and periodic data audits. Rule 13 of the DPDP Rules 2025 adds an annual DPIA and audit with a report to the Board, algorithmic due diligence, and localisation of any personal data the Central Government specifies.

Engineering implication: If your organisation is designated an SDF, you must: (a) appoint a DPO based in India, responsible to the Board of Directors; (b) appoint an independent data auditor; (c) run a DPIA and audit once in every twelve months and have the assessor furnish a report of significant observations to the Board (Rule 13(1)–(2)). Until the Government publishes designation notifications, no organisation should assume SDF status — but organisations processing large volumes of Indian personal data should prepare for possible designation.

5. Consent Manager

Statutory definition (Section 2(g)):

"a person registered with the Board, who acts as a single point of contact to enable a Data Principal to give, manage, review and withdraw her consent through an accessible, transparent and interoperable platform"

Plain-English translation: A regulated third-party intermediary — registered with the Data Protection Board — that provides a centralised consent management interface. A Data Principal can use a Consent Manager to grant and revoke consent across multiple Fiduciaries from a single platform, rather than managing consent separately on each product.

Engineering implication: A Consent Manager is not an internal feature or cookie banner. It is a Board-registered legal entity. Rule 4 and the First Schedule of the DPDP Rules 2025 (in force 13 November 2026) require it to be a company incorporated in India with a net worth of at least ₹2 crore, to keep a record of consents given, denied or withdrawn, the notices behind them, and any sharing with a transferee Data Fiduciary, to keep that record for at least seven years, and to make the shared personal data unreadable to itself. If your product plans to integrate with a Consent Manager, your consent API must support machine-readable consent artefact exchange. Your own internal consent flows (for consents granted directly to you, not via a Consent Manager) are governed by Section 6 — the Consent Manager framework is a separate interoperability layer.

6. Data Protection Board of India

Statutory definition (Section 2(c) + Section 18):

"Board" means the Data Protection Board of India established by the Central Government under section 18

Plain-English translation: The regulatory and adjudicatory body for DPDPA. It receives breach intimations, inquires into complaints from Data Principals and into references from the Central or a State Government or directions of a court (Section 27(1)), and imposes the monetary penalties specified in the Schedule to the Act (Section 33(1)). It functions, as far as practicable, as a digital office (Section 28(1)). The Board's orders are appealable to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT) (Section 29).

Engineering implication: Your breach notification pipeline must support the two clocks in Rule 7(2) of the DPDP Rules 2025: an initial intimation to the Board "without delay" describing the breach, including its nature, extent, timing and location of occurrence and the likely impact (Rule 7(2)(a)); then, within 72 hours of becoming aware of the breach (or a longer period the Board allows on a written request), a detailed report covering updated details, the broad facts and reasons behind the breach, mitigation measures, any findings about the person who caused it, remedial measures, and a report on the intimations given to affected Data Principals (Rule 7(2)(b)). Each affected Data Principal must also be told "without delay" (Rule 7(1)). The Board can demand evidence of your Rule 6 security safeguards during an inquiry — treat your SIEM access logs and breach incident record as Board artefacts.

7. Data Protection Officer (DPO)

Statutory definition (Section 2(l) + Section 10(2)(a)):

"Data Protection Officer" means an individual appointed by the Significant Data Fiduciary under clause (a) of sub-section (2) of section 10

Section 10(2)(a) requires the DPO to represent the SDF under the Act, be based in India, be responsible to the Board of Directors or similar governing body, and be the point of contact for the grievance redressal mechanism.

Plain-English translation: A mandatory individual role (not a team or a job title) required only for Significant Data Fiduciaries. The DPO must be an individual, based in India, and responsible to the Board of Directors — not buried in a compliance department. Non-SDFs are not required to appoint a DPO, but must publish the business contact information of a person who can answer Data Principals' questions about processing (Section 8(9) and Rule 9).

Engineering implication: For non-SDFs: publish the contact person's business contact information prominently on your website or app and mention it in every response to a rights request (Rule 9). For SDFs: the same applies to the DPO, and every consent request must give the DPO's contact details (Section 6(3)). Every breach intimation to Data Principals must carry the business contact information of a person who can respond on your behalf (Rule 7(1)(e)). Your breach notification template must have these details pre-populated — not a generic privacy@company.com alias.

Data Definitions: What Is Covered?

8. Personal Data

Statutory definition (Section 2(t)):

"any data about an individual who is identifiable by or in relation to such data"

Plain-English translation: Any data that can be used to identify a person — directly (name, Aadhaar, email, phone) or indirectly (device ID + timestamp + location that triangulates to a specific individual). There is no enumerated list of personal data categories in the DPDPA. The test is identifiability, not data type.

Engineering implication: Apply an identifiability test at data classification time, not a category lookup. A database table with user_id, session_id, ip_address, and page_visited is personal data because user_id is directly linked to an individual. Fully aggregated analytics (cohort-level, k-anonymity preserved) may fall outside scope. Pseudonymised data that can be re-identified with a key your organisation holds is still personal data.

9. Personal Data Breach

Statutory definition (Section 2(u)):

"any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data"

Plain-English translation: Any CIA-triad event affecting personal data. This is broader than "exfiltration." Ransomware encrypting a database (loss of availability) is a breach. An accidental S3 bucket exposure (confidentiality) is a breach. A record update without a lawful ground (integrity + unauthorised use) is a breach. The Section 2(u) definition has no severity threshold, and neither does the notification duty: Section 8(6) requires intimation of a personal data breach to the Board and each affected Data Principal, in the form and manner set by Rule 7 of the DPDP Rules 2025.

Engineering implication: Your SIEM correlation rules must classify all three CIA-triad event types — not just exfiltration/exfil events — as breach candidates. Your incident response decision tree starts with "Does this event compromise C, I, or A of personal data?" rather than "Was data exfiltrated?"

10. Processing

Statutory definition (Section 2(x)):

"a wholly or partly automated operation or set of operations performed on digital personal data, and includes operations such as collection, recording, organisation, structuring, storage, adaptation, retrieval, use, alignment or combination, indexing, sharing, disclosure by transmission, dissemination or otherwise making available, restriction, erasure or destruction"

Plain-English translation: Everything done to personal data from collection to deletion. Storing it is processing. Querying it for analytics is processing. Sending it to a third-party API is processing. Deleting it on purpose — or failing to delete it when required — is processing. There is no "passive holding" exception.

Engineering implication: Every stage in your data pipeline is covered. Ingestion → enrichment → storage → analytics → transmission → deletion — each step requires a lawful ground under Section 4. If any pipeline stage lacks an associated purpose and lawful ground in your data inventory, it is unauthorised processing, which is a personal data breach under Section 2(u).

Legal Grounds and Obligations

11. Consent

Statutory definition (Section 6(1)):

Consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action" and must "signif[y] an agreement to the processing of her personal data for the specified purpose."

Plain-English translation: Consent is valid only when it meets all five attributes simultaneously. "Free" means no coercion or bundling with unrelated services. "Specific" means per-purpose. "Informed" means preceded by a Section 5 notice. "Unconditional" means not pre-ticked. "Unambiguous with clear affirmative action" means the Data Principal took a deliberate action to grant it — scrolling past a banner does not count.

Engineering implication: Pre-ticked checkboxes, bundled consent (TOS + marketing in one click), and implied consent via continued app use are all invalid. Implement per-purpose unchecked opt-in flows. Store a consent record for each grant: (principal_id, purpose_id, granted_at, consent_text_version, channel). Withdrawal must be as easy as grant under Section 6(4).

12. Legitimate Use

Statutory definition (Section 7):

A Data Fiduciary may process personal data without consent for: the specified purpose for which the Data Principal voluntarily provided it and has not indicated that she does not consent (7(a)); State subsidies, benefits, services, certificates, licences or permits (7(b)); State functions under law or in the interest of sovereignty, integrity or security of the State (7(c)); legal obligations to disclose information to the State (7(d)); compliance with judgments, decrees or orders (7(e)); medical emergencies (7(f)); epidemics and threats to public health (7(g)); disasters or breakdown of public order (7(h)); and employment purposes (7(i)).

Plain-English translation: The second lawful ground after consent. Where processing falls within one of these enumerated categories, no consent request is required. This is a finite list — not a general "legitimate interests" balancing test like GDPR Article 6(1)(f). The DPDPA has no equivalent to GDPR legitimate interests.

Engineering implication: If you are relying on Section 7 rather than consent, document the specific sub-section (e.g., S.7(i) for employment data) in your data inventory against each processing activity. Do not treat Section 7 as a general "we have a good reason" carve-out — it is an exhaustive statutory list.

13. Purpose Limitation

Statutory definition (Section 6(1) + Section 8(7)):

Section 6(1): consent shall "signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose." Section 8(7): a Data Fiduciary shall, "unless retention is necessary for compliance with any law for the time being in force,— (a) erase personal data, upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier".

Plain-English translation: Personal data may only be used for the declared purpose. Using marketing analytics data for credit scoring without a new consent falls outside the specified purpose consented to under Section 6(1). Retaining customer data indefinitely after the purchase transaction is complete is a Section 8(7) violation. Purpose drives both the lawful ground and the retention ceiling.

Engineering implication: Your data pipeline must tag each record with its purpose_id. When purpose is fulfilled, an automated erasure job must run on that data. Cross-purpose use (e.g., re-using email addresses collected for order confirmation to send promotional content) requires a separate consent record. Purpose tags must propagate to Data Processors via DPA terms.

14. Notice

Statutory definition (Section 5(1) + Rule 3):

Before requesting consent, a Data Fiduciary must give the Data Principal a notice in clear and plain language specifying: the personal data to be collected and its processing purpose; the manner to exercise consent withdrawal and rights; and the manner to file a complaint to the Board (Section 5(1)). Rule 3 of the DPDP Rules 2025 adds that the notice must be understandable independently of any other information, give an itemised description of the personal data, and give a communication link for withdrawing consent, exercising rights and complaining to the Board. Under Section 5(3), the Data Principal must have the option to access the notice in English or any language in the Eighth Schedule to the Constitution (22 languages).

Plain-English translation: The pre-consent disclosure document — your privacy notice. It must be itemised (not a wall-of-legalese), available in 23 languages (22 Eighth Schedule + English), and must specifically tell users how to withdraw consent and complain to the Board. A generic "we may share your data with partners" clause does not satisfy Section 5.

Engineering implication: Your consent UI must load and display the Section 5 notice before presenting the consent request. The notice must be granular per purpose — not a global "privacy policy" link. Store the notice version hash alongside each consent record so you can prove which notice text the user saw when they consented. Multilingual delivery requires Eighth Schedule language detection based on user preference or device locale.

Technical and Operational Terms

15. Technical and Organisational Measures (TOMs)

Statutory definition (Section 8(4), Section 8(5) + Rule 6):

Section 8(4): "A Data Fiduciary shall implement appropriate technical and organisational measures to ensure effective observance of the provisions of this Act and the rules made thereunder." Section 8(5) separately requires "reasonable security safeguards to prevent personal data breach."

Rule 6(1) of the DPDP Rules 2025 (in force 13 May 2027) sets the minimum reasonable security safeguards: (a) data security measures such as encryption, obfuscation, masking or virtual tokens; (b) access control for computer resources; (c) visibility on access through logs, monitoring and review; (d) measures for continued processing, such as data backups; (e) retention of logs and personal data for one year; (f) security provisions in Data Processor contracts; and (g) appropriate technical and organisational measures to ensure effective observance of security safeguards.

Plain-English translation: The engineering and governance controls your organisation must implement under DPDPA. Rule 6(1) is the seven-point minimum checklist. "Appropriate" and "reasonable" are context-dependent — what is appropriate for a 10-person startup differs from a bank, but both must demonstrate a documented response to each Rule 6(1) clause.

Engineering implication: AES-256-GCM at rest, TLS 1.3 in transit, RBAC/ABAC with MFA, structured access event logs kept for at least a year, tested backups, Processor contract security clauses, annual VAPT covering personal data systems, and masking or tokenisation for non-production environments are the current industry benchmarks for Rule 6 compliance. The Rule itself names no cipher suite, standard or testing frequency. Document your TOMs in a formal Statement of Applicability cross-referencing each Rule 6(1) clause. Gaps must be remediated or risk-accepted with documented rationale.

16. Pseudonymisation

Statutory basis (Rule 6(1)(a)): Neither the Act nor the DPDP Rules 2025 define or name pseudonymisation. The closest text is Rule 6(1)(a), which lists as a minimum safeguard:

"appropriate data security measures, such as securing of personal data through encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data"

Plain-English translation: Replacing directly identifying fields (name, email, phone, Aadhaar) with reversible tokens or hashes — so the data can be used for the processing purpose but cannot directly identify the individual without the reverse-mapping key. Pseudonymisation reduces breach impact but does not take data out of scope for DPDPA (unlike anonymisation), since the key holder can re-identify it.

Engineering implication: Implement pseudonymisation in all non-production environments (dev, QA, analytics, ML training). Use a separate key management service to store the pseudonym-to-identity mapping, with access controls stricter than the main personal data store. Pseudonymised copies in analytics pipelines are still personal data — they require the same lawful ground and are subject to erasure obligations.

17. Consent Artefact

Statutory basis (First Schedule, Part B, item 3): Neither the Act nor the DPDP Rules 2025 define "consent artefact". The closest text is the Consent Manager's duty to maintain on its platform a record of:

"(a) Consents given, denied or withdrawn by her; (b) Notices preceding or accompanying requests for consent; and (c) Sharing of her personal data with a transferee Data Fiduciary."

Plain-English translation: The structured data record that proves a Data Principal consented to a specific processing purpose. A Consent Manager must give the Data Principal access to this record, provide it in machine-readable form on request, and keep it for at least seven years (First Schedule, Part B, item 4). Unique IDs, timestamps and signatures are engineering good practice, not statutory requirements. For consents you collect directly, Section 6(10) puts the burden on you to prove that notice was given and consent was obtained.

Engineering implication: Your consent database table is an artefact store. Minimum required fields: artefact_id (UUID), principal_id, purpose_id, consent_text_version, granted_at (ISO 8601), channel (web/app/cm-platform), withdrawn_at (nullable). If using a Consent Manager, artefacts must be machine-readable and exchangeable via the CM's API. Never overwrite artefact records — use immutable append-only storage; update consent state by writing a new row with withdrawn_at populated.

18. Audit Trail

Statutory basis (Rule 6(1)(c)): "Audit trail" is not defined in the Act or the DPDP Rules 2025. The nearest obligation is the Rule 6(1)(c) safeguard:

"visibility on the accessing of such personal data, through appropriate logs, monitoring and review, for enabling detection of unauthorised access, its investigation and remediation to prevent recurrence"

Plain-English translation: A tamper-evident log of every operation performed on personal data and consent records. Distinct from an application log — the audit trail specifically captures who did what to which personal data, when, and for what purpose, not just system events.

Engineering implication: Structured audit trail events must capture: event_id, timestamp (ISO 8601), actor (user/service identity), action (create/read/update/delete/share), resource (table + record id), purpose_id, outcome (success/denied), ip_address. Store audit trails in a write-once (WORM) or append-only store — immutability strengthens their evidential value in a Board inquiry. Retention: Rule 6(1)(e) and Rule 8(3) require logs (and the associated personal data and traffic data) to be kept for at least one year (both apply from 13 May 2027); beyond that, follow your data retention policy and sectoral law requirements (SEBI/RBI timelines as applicable).

Rights and Duties

19. Right to Access and Information (Section 11)

Statutory definition: A Data Principal has the right to obtain a summary of personal data being processed about them and the processing activities, the identities of all other Data Fiduciaries and Data Processors with whom it has been shared (with a description of the data shared), and such other information as may be prescribed (Section 11(1)).

Engineering implication: Implement a subject access request (SAR) endpoint or portal. Rule 14(1) of the DPDP Rules 2025 requires you to publish on your website or app how Data Principals can make rights requests and which identifiers you need to identify them. The notified Rules set no acknowledgment or fulfilment deadline for access requests; a grievance about an unanswered request must be answered within a period not exceeding 90 days (Rule 14(3)), so set your internal SLA well inside that ceiling. Response must cover all personal data processed by you and by your Data Processors on your behalf. Machine-readable export (JSON/CSV) is good practice.

20. Right to Correction and Erasure (Section 12)

Statutory definition: A Data Principal may request correction, completion, updating and erasure of personal data she consented to (Section 12(1)). On an erasure request, the Data Fiduciary must erase the data unless retention is necessary for the specified purpose or for compliance with any law (Section 12(3)). Section 8(7)(b) requires the Data Fiduciary to cause its Data Processors to erase personal data it made available to them.

Engineering implication: Erasure is not a soft delete — it must cascade to all systems holding the data: backups, staging environments, Data Processors, downstream analytics. Build an erasure job that accepts principal_id and propagates deletion across your entire data estate. status: deleted flags do not satisfy Section 12. Propagation to Data Processors must be documented and tracked. Rule 8(3) requires personal data, traffic data and processing logs to be kept for at least one year from processing, for the Seventh Schedule purposes. So on an erasure request, remove the data from active processing and user-facing systems at once, hold any records still inside that one-year window in access-controlled storage used only for those purposes, and erase them when the year ends. This treats Rule 8(3) as a law requiring retention under Section 12(3).

21. Right of Grievance Redressal (Section 13)

Statutory definition: Every Data Fiduciary and Consent Manager must provide readily available means of grievance redressal (Section 13(1)) and respond within the prescribed period (Section 13(2)). Rule 14(3) of the DPDP Rules 2025 requires you to publish that period, a reasonable period not exceeding 90 days, on your website or app, and to meet it. The Data Principal must exhaust this mechanism before approaching the Board (Section 13(3)).

Engineering implication: A static "contact us" email does not satisfy Section 13. Build a grievance portal that: issues a unique reference number on submission and acknowledges promptly (good practice; the Rules set no acknowledgment deadline); tracks resolution status against the 90-day Rule 14(3) ceiling, with internal alerts well before it; and tells the Data Principal how to complain to the Board once the mechanism is exhausted. Non-fulfilment of rights obligations falls under the Schedule's residual item, with a penalty that may extend to ₹50 crore.

22. Right to Nominate (Section 14)

Statutory definition: A Data Principal may nominate another individual to exercise their Section 11–13 rights in the event of death or incapacity.

Engineering implication: Implement a nomination form (nominator + nominee identity verification, relationship type, scope of nomination). Nominee-initiated requests must be treated as the Data Principal's own requests for access, correction, erasure, and grievance purposes.

Cross-Cutting Compliance Concepts

23. Cross-Border Data Transfer (Section 16)

Statutory definition:

"The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified." (Section 16(1))

Plain-English translation: Transfers are permitted by default — Section 16 uses a negative-list model. The Government restricts specific countries by official notification. There is no Board approval step, no positive allowlist of countries, and no general data localisation requirement. Three qualifications: Rule 15 of the DPDP Rules 2025 lets the Central Government specify requirements for making personal data available to a foreign State or its agencies; Rule 13(4) can require an SDF to keep Government-specified personal data in India; and Section 16(2) preserves any stricter sectoral law. Check the Official Gazette for restriction notifications before relying on a destination.

Engineering implication: Your Rego policy or code must implement this correctly: default transfer_allowed := true, blocking only when the destination is on a blocked_countries list published by the Government. A positive approved_countries allowlist is architecturally wrong for DPDPA Section 16 and will break when new unrestricted countries are used. Monitor MeitY official gazette for future restriction notifications.

24. Data Protection Impact Assessment (DPIA)

Statutory definition (Section 10(2)(c)(i) + Rule 13(1)):

"periodic Data Protection Impact Assessment, which shall be a process comprising a description of the rights of Data Principals and the purpose of processing of their personal data, assessment and management of the risk to the rights of the Data Principals, and such other matters regarding such process as may be prescribed"

Rule 13(1) of the DPDP Rules 2025 requires an SDF to undertake a DPIA and an audit once in every period of twelve months, and Rule 13(2) requires the report of significant observations to be furnished to the Board.

Plain-English translation: A structured risk assessment for high-risk personal data processing activities. Mandatory only for Significant Data Fiduciaries. Non-SDFs are not statutorily required to conduct DPIAs, but running them for high-risk processing is good practice under Section 8(4)'s "appropriate technical and organisational measures" standard.

Engineering implication: For SDFs: an annual DPIA framework covering purpose identification, data flow mapping, risk assessment (likelihood × severity of harm to Data Principals), proposed controls, and residual risk acceptance must be in place before launching new high-risk processing activities. For non-SDFs: include a privacy impact checklist in your feature launch process to demonstrate "appropriate technical and organisational measures" under Section 8(4).

25. Penalties (the Schedule to the Act)

Statutory definition (Section 33(1) + the Schedule):

Where the Board determines that a breach is significant, it may impose the monetary penalty specified in the Schedule. Each amount is a ceiling ("may extend to"). Key amounts: S.8(5) security safeguard failure — ₹250 crore; S.8(6) breach notification failure — ₹200 crore; S.9 children's data failure — ₹200 crore; S.10 SDF obligations failure — ₹150 crore; S.15 Data Principal duties — ₹10,000; breach of a voluntary undertaking (S.32) — up to the amount for the underlying breach; any other provision of the Act or Rules (including Data Principal rights) — ₹50 crore.

Plain-English translation: Penalties apply per breach of a provision, not per individual affected. Both S.8(5) and S.8(6) can apply to the same incident, giving a potential aggregate of up to ₹450 crore from a single breach event. The Board determines the exact amount within the ceiling by applying the Section 33(2) factors.

Engineering implication: Your incident response produces regulatory artefacts, not just operational evidence. Section 33(2) factors include: the nature, gravity and duration of the breach; the type and nature of the personal data affected; whether the breach was repetitive; and whether you took action to mitigate its effects, and how timely and effective that action was. Timestamped detection records, Board notification submissions, and documented containment actions are all Section 33 evidence. A SIEM audit trail that proves you detected and responded promptly is a direct penalty-reduction tool.

FAQ: Glossary Misconceptions

Is there a "sensitive personal data" category in the DPDPA 2023?

No. This is the most consequential misconception in the Indian data protection space. The 2019 PDP Bill contained a "sensitive personal data" category — financial records, health data, biometric data, religious beliefs, and others. The enacted DPDPA 2023 removed the category entirely. Under the 2023 Act, financial records, health data, and biometric data of adults are governed by the same uniform Section 8(5) obligation as any other personal data. The only data-type elevation in the 2023 Act is Section 9, which applies exclusively to children under 18.

What is the difference between a Data Fiduciary and a Data Processor?

The test is who determines purpose and means. If your organisation decides why the data is collected and how it will be used, you are a Data Fiduciary. If you execute another organisation's instructions about their data collection, you are a Data Processor. In a B2B SaaS scenario: the SaaS company is typically a Processor; its enterprise customers are typically Fiduciaries. A SaaS company can be both — a Fiduciary for data it collects about its own users and a Processor for data its customers load into the platform. Section 8(5) liability flows to the Fiduciary regardless of which entity caused the breach.

Does the DPDPA require all companies to appoint a Data Protection Officer?

No. A DPO is mandatory only for Significant Data Fiduciaries designated by the Central Government under Section 10. All other Data Fiduciaries must publish the business contact information of a person who can answer Data Principals' questions about processing (Section 8(9)) — this is not a DPO. There is also no DPO qualification requirement specified in the Act for non-SDFs. Rule 9 requires the contact details to be published prominently on the website or app and mentioned in every response to a rights request.

What does "processing" include — does just storing data count?

Yes. Section 2(x)'s definition of "processing" explicitly includes "storage." Collecting data is processing. Querying it is processing. Backing it up is processing. Deleting it (or failing to delete it) is processing. There is no passive or inert state for personal data under DPDPA — once data exists in your systems, you are processing it and the lawful ground requirement under Section 4 applies.

Does the DPDPA apply to personal data about employees?

Yes, with a carve-out. Section 7(i) permits processing without consent "for the purposes of employment or those related to safeguarding the employer from loss or liability", such as prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property or classified information, or providing a service or benefit the employee has sought. The DPDP Rules 2025 add no employment-specific rule; Section 8(7) erasure still applies once the purpose is served, unless a law requires longer retention. Employee data processed beyond employment purposes (e.g., using employee emails for unrelated marketing) requires a separate lawful ground.

Build Your DPDPA Compliance Stack on Accurate Definitions

Compliance starts with language precision. A team that conflates Data Fiduciary with Data Processor writes the wrong DPAs, builds the wrong notification pipeline, and faces the wrong penalty exposure. A team that believes DPDPA has a sensitive data category implements unnecessary controls while missing the actual Rule 6 security safeguards.

StateCheck Security provides DPDPA compliance audits that trace each obligation from the statutory definition through to the engineering implementation — consent schema, breach notification pipeline, data inventory, DSR portal, and processor contract review.

Request a DPDPA compliance audit → to identify gaps in your implementation before the Board does.