FACEOFF TECHNOLOGIES — DPDP AND DATA PRIVACY REFERENCE ======================================================================== Source: https://faceoff.world Scope: India's Digital Personal Data Protection Act, 2023 and the FaceOff-Privacy platform that implements it. Disambiguation: "FaceOff" means FaceOff Technologies, an enterprise software company. Not the 1997 film. ACCURACY NOTE Regulatory dates below reflect the DPDP Rules as notified on 13 November 2025 and publicly reported phasing. Verify against the official notification before relying on them contractually. Product metrics marked illustrative are targets, not measured results. ======================================================================== 1. WHAT THE DPDP ACT REQUIRES ======================================================================== Sec. 4 & 7 — Lawful grounds Personal data may be processed only for a lawful purpose, with consent or for a listed legitimate use. Sec. 5 — Notice Itemised notice: what data, what purpose, how to exercise rights, how to complain to the Board — in English or any Eighth Schedule language. Sec. 6 — Consent Free, specific, informed, unconditional, unambiguous, by clear affirmative action. Withdrawal as easy as giving. Sec. 8 — Fiduciary duties Accuracy, technical and organisational measures, reasonable security safeguards, erasure on withdrawal, published DPO contact — and liability for processors. Sec. 9 — Children Verifiable parental or guardian consent; no tracking or behavioural advertising directed at children. Sec. 10 — Significant Data Fiduciary DPO based in India, independent data auditor, periodic DPIA and audit, algorithmic due diligence. Sec. 11–14 — Principal rights Access summary, correction and erasure, grievance redressal, nomination. Sec. 16 — Cross-border Transfer permitted except to countries restricted by the Central Government by notification. PENALTIES (Schedule, assessed per instance) Up to Rs 250 crore — failing to take reasonable security safeguards Up to Rs 200 crore — failing to intimate a personal data breach Up to Rs 200 crore — children's data failures Up to Rs 150 crore — Significant Data Fiduciary missing Sec. 10 duties Up to Rs 50 crore — other contraventions ======================================================================== 2. ENFORCEMENT TIMELINE ======================================================================== 13 Nov 2025 — DPDP Rules notified The Rules were notified, turning the 2023 Act into operative obligations with detail on notice, consent, security safeguards and breach reporting. From Nov 2025 — Data Protection Board stands up The Board becomes operational and the complaint mechanism goes live, so a Data Principal has somewhere to take a grievance. ~Nov 2026 — Consent Manager registration opens Consent Managers — registered intermediaries with a minimum net worth of ₹2 crore — can register with the Board. Fiduciaries that intend to interoperate need their consent artefacts in the right shape before this. 13 May 2027 — Full compliance required Every organisation processing digital personal data in India must be fully compliant. Enterprise programmes typically run 9–12 months from gap assessment to audit readiness, so the window to start is now. Enterprise programmes typically require 9-12 months from gap assessment to audit readiness. ======================================================================== 3. GLOSSARY ======================================================================== Data Fiduciary (Sec. 2(i)) The organisation that decides why and how personal data is processed. Any person who, alone or with others, determines the purpose and means of processing personal data. The Fiduciary carries the obligations under the Act and remains responsible for processing carried out on its behalf by a Data Processor — which is the structural trap in Sec. 8(1): you inherit the penalty for your vendor's failure. Data Principal (Sec. 2(j)) The individual the personal data is about. The individual to whom the personal data relates. Where the individual is a child, it includes the parent or lawful guardian; where the individual is a person with disability, it includes their lawful guardian. The Principal holds the rights of access, correction, erasure, grievance redressal and nomination. Data Processor (Sec. 2(k)) A vendor processing personal data on the Fiduciary's behalf. Any person who processes personal data on behalf of a Data Fiduciary. Processors must be engaged under a valid contract, and the Fiduciary stays liable for their processing — which is why a processor register mapped to purposes and consents is the difference between mapped exposure and discovered exposure. Significant Data Fiduciary (SDF) (Sec. 10) A Fiduciary notified by government as carrying elevated duties. The Central Government may notify any Data Fiduciary or class of Fiduciaries as Significant, based on the volume and sensitivity of personal data processed, risk to Data Principals, and factors including sovereignty, electoral democracy and public order. An SDF must appoint an India-based DPO answerable to the board, appoint an independent data auditor, and undertake periodic DPIAs, audits and algorithmic due diligence. Notification is by class — an enterprise can become an SDF without changing anything it does. Consent Manager (Sec. 2(g), 6(7)–(9)) A registered intermediary, not the software you run in-house. A person registered with the Data Protection Board who acts as a single point of contact enabling a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform. Registration carries a minimum net-worth requirement. This is commonly confused with a Consent Management Platform, which is the software an organisation deploys internally — a Consent Manager is a regulated intermediary standing between Principals and multiple Fiduciaries. Consent Management Platform (CMP) The software you deploy to capture and enforce consent. The system a Data Fiduciary runs to capture, store, enforce and evidence consent across its own channels and downstream systems. Distinct from a registered Consent Manager. A CMP that only records consent without enforcing it downstream leaves the Fiduciary exposed: consent that no system checks before processing is a record, not a control. Personal data breach (Sec. 2(u)) Broader than a hack — it includes loss of access. Any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data. The definition covers unauthorised internal processing and loss of access, not only external exfiltration, which is why detection scoped to attack alone under-reports. Notice (Sec. 5) The itemised statement served before or with consent. A statement itemising the personal data to be collected, the purpose of processing, how the Data Principal may exercise their rights, and how to complain to the Board. It must be available in English or any language in the Eighth Schedule to the Constitution — twenty-two languages besides English. Legitimate uses (Sec. 7) The narrow set of grounds that do not need consent. The specified circumstances in which personal data may be processed without consent, including where the Principal has voluntarily provided data for a purpose, for State functions and subsidies, for compliance with law or a court order, for medical emergencies, and for employment purposes. Narrower than the GDPR's legitimate-interest balancing test — it is a closed list rather than an assessment. Data Protection Board of India (Sec. 18, 27, 28) The regulator that inquires and imposes penalties. The adjudicating body established under the Act. It inquires into breaches and complaints and determines penalties, weighing the nature, gravity and duration of the breach, the type of personal data affected, repetitive conduct, and any mitigating action taken promptly. An inability to produce records under a Sec. 28 inquiry does not attract its own penalty — it removes the defence against every other one. Data Protection Officer (DPO) (Sec. 8(9), 10(2)(a)) The accountable individual, based in India, for an SDF. The individual an SDF must appoint to be the point of contact for grievance redressal, based in India and answerable to the board of directors or equivalent governing body. Every Data Fiduciary must publish the contact details of the DPO or of a person able to answer questions about its processing. DPIA / Privacy Impact Assessment (Sec. 10(2)(c)) The periodic assessment an SDF must run. A process comprising a description of the rights of Data Principals and the purpose of processing, assessment and management of risk to those rights, and such other matters as prescribed. An SDF must undertake DPIAs periodically, alongside periodic audit and due diligence of algorithmic software. Algorithmic due diligence (Sec. 10(2)(c)(iii)) The obligation that makes AI governance statutory. The duty on an SDF to undertake due diligence to verify that algorithmic software it deploys for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data does not pose a risk to the rights of Data Principals. This is the clause that turns model inventory, bias testing and human oversight from good practice into a compliance obligation. Erasure on withdrawal (Sec. 8(7)–(8)) Consent withdrawal triggers deletion, not just a flag. On withdrawal of consent, or as soon as it is reasonable to assume the specified purpose is no longer being served, the Fiduciary and its Processors must erase the personal data unless retention is necessary for compliance with law. Delivering this depends on being able to enumerate every store holding that individual's data. Cross-border transfer (Sec. 16) Permitted by default, restricted by notification. Transfer of personal data outside India is permitted except to territories the Central Government restricts by notification. This is a negative-list model rather than the adequacy-decision model used under GDPR, so the control is evaluating each transfer against the current restricted list at processing time. Verifiable parental consent (Sec. 9) Required before processing a child's data. Before processing the personal data of a child — anyone under eighteen — the Fiduciary must obtain verifiable consent from a parent or lawful guardian, and must not undertake tracking, behavioural monitoring or targeted advertising directed at children. Failures here sit in the ₹200 crore penalty band. ======================================================================== 4. OBLIGATION TO PRODUCT OWNERSHIP ======================================================================== Lawful purpose & legitimate uses (Sec. 4, 7) Primary: Privacy Program Governance Supporting: Consent Management Itemised notice, multi-language (Sec. 5) Primary: Consent Management Supporting: Intelligent Data Mapper, Privacy Program Governance Consent: specific, informed, affirmative (Sec. 6(1)) Primary: Consent Management Supporting: Privacy Program Governance Withdrawal parity & cessation (Sec. 6(4)–(6)) Primary: Consent Management Supporting: Intelligent Data Mapper, Privacy Program Governance Consent Manager interoperability (Sec. 6(7)–(9)) Primary: Consent Management Supporting: none Processor accountability (Sec. 8(1)–(2)) Primary: Privacy Program Governance Supporting: Data Anonymization & Masking, Audit & Evidence Management Accuracy where used for decisions (Sec. 8(3)) Primary: Intelligent Data Mapper Supporting: Privacy Program Governance Technical & organisational measures (Sec. 8(4)) Primary: Data Anonymization & Masking Supporting: PIA / DPIA Assessment, Audit & Evidence Management Reasonable security safeguards (Sec. 8(5)) Primary: Data Anonymization & Masking Supporting: Data Breach Management, Audit & Evidence Management Breach intimation to Board & Principals (Sec. 8(6)) Primary: Data Breach Management Supporting: Intelligent Data Mapper, Audit & Evidence Management Erasure on withdrawal / purpose expiry (Sec. 8(7)–(8)) Primary: Intelligent Data Mapper Supporting: DSAR Management, Consent Management Published DPO contact & grievance (Sec. 8(9)–(10)) Primary: Audit & Evidence Management Supporting: DSAR Management Children's data & parental consent (Sec. 9) Primary: Consent Management Supporting: PIA / DPIA Assessment, Intelligent Data Mapper SDF: DPO, auditor, DPIA, algorithms (Sec. 10) Primary: PIA / DPIA Assessment Supporting: Audit & Evidence Management, Privacy Program Governance Access summary & sharing lineage (Sec. 11) Primary: DSAR Management Supporting: Intelligent Data Mapper, Data Anonymization & Masking Correction, completion & erasure (Sec. 12) Primary: DSAR Management Supporting: Intelligent Data Mapper Grievance redressal & nomination (Sec. 13, 14) Primary: DSAR Management Supporting: Audit & Evidence Management Cross-border transfer restrictions (Sec. 16) Primary: Privacy Program Governance Supporting: Intelligent Data Mapper ======================================================================== 5. PRODUCTS AND THEIR DPDP ALIGNMENT ======================================================================== ------------------------------------------------------------------------ CONSENT MANAGEMENT ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/consent-management Primary DPDP sections: Sec. 5, 6, 9 Obtain, record and manage explicit permission for every processing purpose — across every channel, in every jurisdiction, from a single record of truth. Capabilities: Purpose-level consent ledger; Multi-language notice engine; Real-time enforcement API Outcome: Consent that is not merely recorded but enforced — every downstream system checks before it processes, and withdrawal actually stops the processing. Transparency & communication Plain-language notice at the point of collection, plus a self-service centre where an individual can see and change every consent given. - Notice templates versioned per purpose - 22 Eighth Schedule languages plus English - Every notice served is replayable - Preference centre in any channel Granular consent & control Purpose-level opt-in rather than a single blanket toggle — and withdrawal made exactly as easy as the original consent. - Consent object scoped to one purpose - Affirmative capture with timestamp - Consent bound to the notice version shown - One-click withdrawal, parity enforced Automated & centralised management One consent store, updated in real time, that every downstream system must query before it processes. - Real-time consent API at query time - Event fan-out to processors on change - Consent Manager-ready interoperability - Age-band gating and guardian flows DPDP alignment, section by section: Sec. 5 Requires: Itemised notice describing the personal data, the purpose, how to exercise rights and how to complain to the Board — in English or any Eighth Schedule language. Satisfied by: A templated notice engine renders per purpose, versioned and localised into all 22 scheduled languages. Every notice served is stored and replayable against the Principal who saw it. Sec. 6(1) Requires: Consent must be free, specific, informed, unconditional and unambiguous, by clear affirmative action, limited to data necessary for the specified purpose. Satisfied by: Consent is captured as a purpose-scoped object with an affirmative-action event, an immutable timestamp and a binding to the exact notice version displayed. Blanket consent is structurally impossible. Sec. 6(4)–(6) Requires: Withdrawal must be as easy as giving. Processing must cease within a reasonable time, and processors must be made to cease too. Satisfied by: One-click withdrawal with click-parity enforced against the give-flow. Revocation fans out to every processor that inherited the consent; cessation is tracked to an SLA and evidenced. Sec. 6(7)–(9) Requires: A Consent Manager registered with the Board must give the Principal an accessible, transparent and interoperable platform to manage consent. Satisfied by: Consent artefacts are emitted in an interoperable format with Consent Manager-ready APIs, so registration and integration are configuration rather than a rebuild. Sec. 9 Requires: Verifiable parental consent for children and persons with a guardian; no tracking or behavioural advertising directed at children. Satisfied by: Age-band assurance gates the flow into a guardian consent path, and a child flag suppresses tracking and behavioural advertising downstream automatically. Exposure avoided: Sec. 9 failures carry up to ₹200 Cr under the Schedule. Consent defects also invalidate the lawful basis for every downstream processing activity — one control gap becomes estate-wide exposure. ------------------------------------------------------------------------ COOKIE COMPLIANCE ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/cookie-management Primary DPDP sections: Sec. 6(1) A continuous governance loop that finds cookies, classifies them, gates them behind consent and watches for drift. Shipped as part of Consent Management. Capabilities: Scheduled estate-wide scanning; AI + rules classification; Prior-blocking script Outcome: The banner stops being a decorative overlay and becomes an enforcement point — nothing non-essential fires before the affirmative action. Deep scanning Scheduled crawls across pages, SPAs, subdomains and authenticated journeys find every cookie, pixel, tag and storage entry. - Single-page apps and authenticated journeys - Subdomain and multi-property coverage - Pixels, tags and local storage, not just cookies - Scheduled rescans rather than a one-off audit Auto-classification & prior blocking AI and rules map each cookie to Necessary, Functional, Analytics or Marketing — and non-essential tags stay dormant until the visitor opts in. - Vendor, purpose and duration resolved per cookie - Default-deny behaviour regulators expect - Equal Accept and Reject prominence - No pre-ticked boxes, granular per-category toggles Drift monitoring New or rogue cookies trigger DPO alerts and auto-refresh the cookie policy and banner declarations. - Alerts on cookies no scan previously saw - Policy and declarations refreshed automatically - Geo-targeted banners for DPDP, GDPR and CCPA - Withdrawal as easy as the original consent DPDP alignment, section by section: Sec. 6(1) Requires: Consent must be by clear affirmative action, and processing may not begin before it is given. Satisfied by: Prior blocking is the control that makes this real: a tag firing before the affirmative action means processing began without consent, and no receipt can retrofit it. Sec. 6(4) Requires: Withdrawal must be as easy as giving consent. Satisfied by: The banner exposes a persistent re-open control with equal Accept and Reject prominence, so withdrawal is the same number of clicks as the original grant. Sec. 5 Requires: Notice must itemise what is collected and for what purpose. Satisfied by: Cookie declarations are generated from the live scan, so the published policy matches what the site actually sets rather than what it set at launch. Exposure avoided: A tag that fires pre-consent is unlawful processing from the first pageview, and it is the single easiest defect for a regulator or a journalist to verify from outside your perimeter. ------------------------------------------------------------------------ DSAR MANAGEMENT ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/dsar-management Primary DPDP sections: Sec. 11–14 Individuals have a right to see, correct and erase what you hold about them. This turns that right into a workflow with a clock, an owner and an evidence trail. Capabilities: Automated intake & routing; Catalogue-driven fulfilment; Clock and SLA tracking Outcome: Rights fulfilled inside the statutory window at volume, with the identity check, the redaction and the evidence produced as a by-product of the workflow. Access to personal data The requester sees what is held and how it is processed — assembled from the catalogue rather than from an email thread. - Summary assembled from the live catalogue - Processing activities disclosed with it - Identities of recipients where required - Delivered in a portable format Compliance & process Identity verified before disclosure, response inside the statutory window, extendable only where the law allows. - Identity proofing before any disclosure - Clock starts on receipt and is tracked - Escalation before the deadline, not after - Full trail of who accessed what Enterprise scale Automated intake and fulfilment at volume, with third-party data redacted or anonymised before release. - Automated intake across channels - Bulk handling without linear headcount - Third-party data redacted automatically - Grievance and nomination handled too DPDP alignment, section by section: Sec. 11 Requires: The Principal may obtain a summary of personal data being processed, the processing activities, and the identities of other Fiduciaries with whom it has been shared. Satisfied by: The summary is generated from the live catalogue and the consent ledger, including sharing lineage — so recipients are named from records rather than reconstructed from memory. Sec. 12(1) Requires: The Principal may request correction, completion and updating of their personal data. Satisfied by: Corrections propagate to every store the catalogue identifies, and the propagation itself is evidenced, so accuracy is fixed estate-wide rather than in one system. Sec. 12(3) Requires: The Principal may request erasure, and the Fiduciary must erase unless retention is necessary for a specified purpose or legal compliance. Satisfied by: Erasure executes against the discovered store list; legal-hold and retention exceptions are recorded with the basis relied on, so a refusal is defensible. Sec. 13 Requires: The Fiduciary must provide a readily available grievance redressal mechanism and respond within the prescribed period. Satisfied by: Grievances are first-class tickets with their own clock, routed to the DPO, and evidenced end to end for the Board. Sec. 14 Requires: The Principal may nominate an individual to exercise their rights in the event of death or incapacity. Satisfied by: Nomination is captured, verified and honoured as an authorised path into the same rights workflow. Exposure avoided: Rights failures fall in the residual ₹50 Cr band, but they are the most visible: every missed DSAR is a Principal with a live grievance and a direct route to the Data Protection Board. ------------------------------------------------------------------------ INTELLIGENT DATA MAPPER ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/data-mapper Primary DPDP sections: Sec. 8(3), 8(7) You cannot protect, redact, erase or report on what you have not found. Discovery locates and classifies personal and sensitive data across the entire estate. Capabilities: Continuous estate-wide scanning; AI classification models; Identity-resolved catalogue Outcome: A live catalogue that answers "where is this person's data?" as a query — which is what makes every rights, erasure and breach obligation achievable inside its clock. Systematic detection & management Continuous scanning of structured and unstructured sources, with automated classification and ongoing monitoring rather than a one-off inventory. - Structured, unstructured and semi-structured - Scheduled and event-triggered rescans - Drift detection as new stores appear - Identity resolution across systems AI-powered accuracy Models that confirm sensitive data with high precision and adapt as new data patterns and regulatory definitions emerge. - Context-aware classification, not regex - Confidence scoring with human review - Retraining as new patterns emerge - Extensible to new data categories Data integrity & compliance Invalid and stale elements are flagged and corrected, and every scan leaves a detailed audit trail. - Accuracy and staleness flagging - Lineage from source to consumer - Detailed audit trail per scan - Feeds DSAR, redaction and erasure DPDP alignment, section by section: Sec. 8(3) Requires: Ensure completeness, accuracy and consistency of personal data where it is used to make a decision affecting the Principal or is disclosed to another Data Fiduciary. Satisfied by: Discovery maps every copy of an attribute across the estate and flags divergence between them, so accuracy is measured against all copies rather than the system of record alone. Sec. 8(7) Requires: Erase personal data on withdrawal of consent or when the purpose is no longer being served, unless retention is legally required. Satisfied by: The catalogue returns every store holding a given Principal's data, so erasure runs against a complete list — and the completeness itself is evidenced rather than assumed. Sec. 5 Requires: Notice must itemise the personal data being collected — which requires knowing what is actually collected. Satisfied by: Discovery reconciles the data declared in notice against the data actually present, surfacing collection that no notice covers. Sec. 11–12 Requires: The Principal may obtain a summary of personal data held and processing activities, and may request correction, completion, updating and erasure. Satisfied by: Access and correction resolve against a live, identity-resolved catalogue instead of a manual hunt across systems and owners. Sec. 8(6) Requires: Breach intimation must reach every affected Data Principal. Satisfied by: When an incident is scoped to systems, the catalogue converts that into the exact list of affected Principals — turning notification from an investigation into a query. Exposure avoided: Erasure and accuracy failures sit in the ₹50 Cr residual band, but the greater exposure is derivative: without discovery, Sec. 8(6), 11 and 12 all become undeliverable inside their statutory windows. ------------------------------------------------------------------------ DATA ANONYMIZATION & MASKING ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/data-masking Primary DPDP sections: Sec. 8(4), 8(5) Obscure sensitive information inside live data sets so the data stays usable — for analytics, testing, support and disclosure — without exposing the individual. Capabilities: Static & dynamic masking; AI detection in free text; Role and purpose-aware rules Outcome: A smaller blast radius before anything goes wrong — non-production, analytics and vendor estates stop holding raw personal data at all. Comprehensive enterprise solution Handles large volumes, adapts to new categories of personal data, and integrates with existing storage and processing infrastructure. - Scales to enterprise data volumes - Adapts to new personal data categories - Integrates with existing pipelines - Static masking and dynamic redaction AI-powered redaction Detects, identifies and redacts against defined criteria with far greater precision and speed than rule-only approaches. - Context-aware detection in free text - Documents, images and logs covered - Precision tuned per data category - Consistent tokens preserve joinability Custom redaction mechanisms Protocols tuned to the nature and context of the data, automated by rule, with rules that are easy to update as policy changes. - Rules by role, purpose and context - Format-preserving where analytics need it - Policy changes without a code release - Every redaction decision logged DPDP alignment, section by section: Sec. 8(4) Requires: Implement appropriate technical and organisational measures to ensure effective observance of the Act. Satisfied by: Masking is enforced as a technical control at the data layer rather than a policy instruction to teams, so observance does not depend on individual discipline. Sec. 8(5) Requires: Take reasonable security safeguards to prevent a personal data breach. Satisfied by: Data masked in non-production, analytics and vendor estates cannot be breached in those estates — the safeguard reduces the population at risk instead of only defending it. Sec. 8(1)–(2) Requires: The Fiduciary remains responsible for processing carried out by a processor engaged under contract. Satisfied by: Masked extracts are what leaves for vendors and test environments, so processor exposure is bounded by design rather than by contract language alone. Sec. 11 Requires: The access summary must be delivered to the requesting Principal — and only to them. Satisfied by: Third-party personal data appearing in a DSAR response is redacted automatically before release, so fulfilling one right does not breach another Principal's. Sec. 6(1) Requires: Consent is limited to the personal data necessary for the specified purpose. Satisfied by: Masking enforces minimisation in practice: downstream consumers receive only the fields their purpose actually requires. Exposure avoided: Failure to take reasonable security safeguards under Sec. 8(5) is the single largest item in the Schedule at up to ₹250 Cr. Masking is the control most directly responsive to it. ------------------------------------------------------------------------ PIA / DPIA ASSESSMENT ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/pia-dpia Primary DPDP sections: Sec. 10(2) A systematic process to evaluate and manage the privacy risk of any project, initiative or technology that processes personal data — before it reaches production. Capabilities: Design-phase triggering; Multi-regime mapping; Risk register with owners Outcome: Privacy risk found and priced before it ships — and a documented assessment record ready for a Board inquiry or an independent auditor without a scramble. Workflow & integration Assessments triggered from the design phase and carried through the project lifecycle, rather than retrofitted at launch. - Triggered from intake or CI/CD - Threshold screening decides who needs one - Risks tracked to closure, not to filing - Reassessment on material change Legal & regulatory frameworks One assessment mapped to GDPR DPIA, DPDP and other regimes, with documentation held ready for regulatory review. - One record, many regulatory outputs - Mapped to GDPR Art. 35 and DPDP Sec. 10 - Documentation retained for the Board - Versioned decision history Assessment process Identify what needs a PIA; assess nature, scope, context and purpose; evaluate and mitigate risk to rights and freedoms. - Nature, scope, context and purpose - Necessity and proportionality tested - Risk to rights scored and mitigated - Residual risk signed off by an owner DPDP alignment, section by section: Sec. 10(2)(c)(i) Requires: A Significant Data Fiduciary must undertake periodic Data Protection Impact Assessments. Satisfied by: Assessments run on a defined schedule per processing activity, with completion, findings and residual risk tracked as a live posture rather than an annual artefact. Sec. 10(2)(c)(ii) Requires: A Significant Data Fiduciary must undertake periodic audit. Satisfied by: Assessment findings feed the audit workflow directly, so the auditor tests against the same record the business used to make the decision. Sec. 10(2)(a) Requires: Appoint a Data Protection Officer based in India, answerable to the board or its equivalent. Satisfied by: The DPO is a first-class role in the workflow with named approval gates, so accountability is recorded per decision rather than asserted in a policy. Sec. 10(2)(c)(iii) Requires: Undertake such other measures as prescribed, including due diligence of algorithmic software that may risk the rights of Data Principals. Satisfied by: Algorithmic due diligence is a dedicated assessment type covering model purpose, training data provenance, bias testing and human oversight. Sec. 8(4) Requires: Implement appropriate technical and organisational measures to ensure effective observance of the Act. Satisfied by: Every mitigation decision is recorded against the processing activity it protects, so “appropriate measures” is demonstrable rather than declarative. Exposure avoided: Sec. 10 failures carry up to ₹150 Cr. SDF notification is at the Central Government's discretion by class of fiduciary — an enterprise can become subject to these duties without changing anything it does. ------------------------------------------------------------------------ DATA BREACH MANAGEMENT ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/breach-management Primary DPDP sections: Sec. 8(6) Structured detection, investigation, containment, remediation and reporting — so an incident stays an incident and does not become a penalty. Capabilities: Real-time detection; Catalogue-driven scoping; Multi-regime notification Outcome: Notification becomes a query against the catalogue rather than a three-week investigation — the difference between meeting the window and missing it. Detection & investigation Continuous monitoring with real-time alerting, then rapid forensics to establish scope, root cause and the data affected. - Real-time alerting on anomalies - Forensic timeline reconstruction - Scope resolved to data, not just systems - Affected Principals from the catalogue Containment & remediation Immediate isolation of affected systems, vulnerabilities patched and corrective controls put in to prevent recurrence. - Isolation playbooks per system class - Root cause tracked to a fix - Corrective controls verified, not assumed - Recurrence testing after closure Notification, reporting & review Notifications aligned to DPDP, GDPR and CPRA timelines, full audit trail retained, and impact scored in a post-incident review. - Board and Principal intimation drafted - Multi-regime clocks tracked in parallel - Complete trail retained for inquiry - Impact scored and posture updated DPDP alignment, section by section: Sec. 8(6) Requires: In the event of a personal data breach, intimate the Data Protection Board and each affected Data Principal in the form and manner prescribed. Satisfied by: Incident scope resolves through the catalogue into the exact list of affected Principals, and intimations to both the Board and each Principal are generated, tracked and evidenced from that list. Sec. 8(5) Requires: Take reasonable security safeguards to prevent a personal data breach. Satisfied by: Safeguards are evidenced continuously before an incident rather than reconstructed after one — which is what makes the defence available when the Board asks. Sec. 2(u) Requires: A personal data breach includes unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access. Satisfied by: The definition is broader than exfiltration, so detection covers unauthorised internal processing and loss of access, not only external attack. Sec. 28 Requires: The Board may inquire into a breach and determine whether penalty is warranted, taking account of mitigating action taken promptly. Satisfied by: The full incident trail — detection, containment, remediation and intimation, each timestamped — is the record the Board weighs when assessing mitigation. Sec. 33 Requires: Penalty is determined by the nature, gravity and duration of the breach, the type of data affected, repetition, and mitigating action. Satisfied by: Every factor the Board weighs is a field in the incident record, so the mitigation argument is evidenced rather than narrated after the fact. Exposure avoided: Up to ₹250 Cr for failing to prevent a breach and a further ₹200 Cr for failing to intimate it — the two largest items in the Schedule, and they can attach to the same incident. ------------------------------------------------------------------------ AUDIT & EVIDENCE MANAGEMENT ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/audit-evidence Primary DPDP sections: Sec. 10(2)(b) A thorough, repeatable review of how data is actually handled — so adherence to privacy law is verified from evidence rather than asserted from policy. Capabilities: Immutable evidence trail; Scoped auditor workspace; Requirement reconciliation Outcome: Proving compliance becomes a query rather than a quarter — the evidence is generated by running the platform, not assembled when the auditor calls. Comprehensive enterprise solution Integrates into existing data management systems and centralises protection activity including redaction and consent. - One evidence store across products - Immutable, timestamped audit trail - Control library mapped to each regime - Continuous testing, not point-in-time External & internal audit Documentation and processing logs on demand, and evidence handed to external auditors without exposing the underlying sensitive data. - Auditor workspace with scoped access - Evidence served masked by default - Sampling without raw export - Findings tracked to remediation Reconciliation charts Visual reconciliation of real data-handling practice against each compliance requirement, regulation by regulation. - Requirement-to-control reconciliation - Gaps surfaced with named owners - Trend view across audit cycles - Board-ready reporting from the trail DPDP alignment, section by section: Sec. 10(2)(b) Requires: A Significant Data Fiduciary must appoint an independent data auditor to carry out data audit and evaluate compliance with the Act. Satisfied by: A scoped auditor workspace serves documentation and processing logs on demand, masked by default — the auditor gets evidence without being granted the estate. Sec. 8(9) Requires: Publish the business contact information of the DPO or a person able to answer questions about processing. Satisfied by: Contact publication, the queries received against it and the responses given are all held in one evidenced trail. Sec. 8(10) Requires: Establish an effective grievance redressal mechanism. Satisfied by: Grievance volumes, response times and outcomes are reportable as evidence that the mechanism is effective in practice, not merely established on paper. Sec. 28 Requires: The Data Protection Board may conduct an inquiry and require production of records and information. Satisfied by: Board-facing evidence packages are assembled from the same trail that runs the operational controls, so production is a query rather than a reconstruction. Sec. 8(4) Requires: Implement appropriate technical and organisational measures to ensure effective observance. Satisfied by: The control library reconciles each requirement to the control that satisfies it and the evidence that proves it, with gaps surfaced against named owners. Exposure avoided: An inability to produce records under a Sec. 28 inquiry does not attract its own penalty — it removes your defence against every other one. Evidence is what converts a control into a mitigation. ------------------------------------------------------------------------ PRIVACY PROGRAM GOVERNANCE ------------------------------------------------------------------------ URL: https://faceoff.world/privacy/privacy-governance Primary DPDP sections: Sec. 4, 7, 10, 16 The control plane over the whole programme — how data is collected, stored, processed and shared, and who is accountable for each of those. Capabilities: Multi-regime control library; Processor & vendor register; Retention and transfer controls Outcome: The next regulation arrives as a mapping onto controls that already run — not as another eighteen-month programme with its own vendor. Comprehensive privacy programme One view across GDPR, CCPA/CPRA, PDPA, NESA, LGPD and DPDP, so every requirement is visible and owned. - RoPA maintained from live systems - One control satisfies many regimes - Requirements mapped to named owners - Posture visible per jurisdiction Automation & efficiency Automated tooling removes manual error from complex compliance tasks and cuts programme operating cost. - Lawful basis recorded per activity - Vendor and processor register - Retention schedules enforced, not filed - Cross-border transfer controls Transparency & trust Meets rising consumer expectation of privacy and turns compliance posture into a commercial asset. - Posture reportable to the board - Evidence reusable in customer diligence - New regulation lands as configuration - Trust as a differentiator, not a cost DPDP alignment, section by section: Sec. 4 & 7 Requires: Personal data may be processed only for a lawful purpose — with consent, or for one of the listed legitimate uses. Satisfied by: Lawful basis is recorded per processing activity and re-tested when the purpose changes, so “legitimate use” is a documented determination rather than a convenient assumption. Sec. 8(1)–(2) Requires: The Data Fiduciary is responsible for processing by a processor engaged under a valid contract, including on the Principal's behalf. Satisfied by: A processor register ties every vendor to the activities, purposes and consents they inherit, and to the contract that permits it — so liability is mapped, not discovered. Sec. 10(1) Requires: The Central Government may notify any Data Fiduciary or class as a Significant Data Fiduciary based on volume, sensitivity and risk factors. Satisfied by: SDF obligations are tracked as a live posture that can be switched on by class, so notification is a configuration change rather than a programme. Sec. 16 Requires: Transfer of personal data outside India is permitted except to countries restricted by the Central Government by notification. Satisfied by: Transfer controls are evaluated against the current restricted list at processing time, with the data flow map showing where each attribute physically resides. Sec. 17 Requires: Exemptions apply for certain purposes, including legal claims, State instrumentalities and research, subject to prescribed standards. Satisfied by: Exemptions are configured as explicit, evidenced exceptions with a named basis and owner — never as an undocumented gap in enforcement. Exposure avoided: Sec. 8(1) is the structural trap: the Fiduciary carries the penalty for a processor's failure. Without a processor register mapped to purposes and consents, that exposure is unquantified. ------------------------------------------------------------------------ AI GOVERNANCE ------------------------------------------------------------------------ URL: https://faceoff.world/ai-governance Primary DPDP sections: Sec. 10(2)(c)(iii) DPDP made algorithmic accountability a statutory duty, not a policy aspiration. Sec. 10(2)(c)(iii) obliges a Significant Data Fiduciary to perform due diligence on algorithmic software that may risk the rights of Data Principals — which means knowing what models you run, on what data, with what oversight. Capabilities: Model register with owners; EU AI Act + DPDP assessment; Decision-level explainability Outcome: Algorithmic due diligence becomes a standing record rather than a scramble — you can show which models touch personal data, how each was assessed, and who signed off the residual risk. Model inventory & lineage A register of every model in production, the personal data it was trained on, the purpose it serves and the decisions it influences. - Models registered with owner and purpose - Training-data provenance recorded - Lineage from data source to decision - Shadow and third-party models surfaced Assessment against nine regimes The same assessment engine that runs DPIAs covers the EU AI Act, so one description of a system produces the output each regulator expects. - EU AI Act risk classification - DPDP Sec. 10 algorithmic due diligence - Bias and fairness testing recorded - Human-oversight design documented Explainability & consensus Detection and classification decisions expose which layer produced them and which dismissed them, so a finding can be defended rather than merely reported. - Per-decision detection chain retained - Layer-level agreement, not a black box - False-positive auditing built in - Provenance tiers on every output DPDP alignment, section by section: Sec. 10(2)(c)(iii) Requires: Undertake such other measures as prescribed, including due diligence of algorithmic software that may risk the rights of Data Principals. Satisfied by: Algorithmic due diligence runs as a dedicated assessment type covering model purpose, training-data provenance, bias testing and human oversight, tracked per model rather than per programme. Sec. 10(2)(c)(i) Requires: A Significant Data Fiduciary must undertake periodic Data Protection Impact Assessments. Satisfied by: Models are assessed on the same cadence and in the same engine as processing activities, so an AI system is never assessed outside the privacy programme that governs its data. Sec. 8(3) Requires: Ensure completeness, accuracy and consistency of personal data where it is used to make a decision affecting the Principal. Satisfied by: Model lineage ties each decision back to the attributes and copies that fed it, so accuracy obligations reach the inputs of automated decisions rather than stopping at the system of record. Sec. 11 Requires: The Principal may obtain a summary of the processing activities performed on their personal data. Satisfied by: Automated processing is disclosed as a named activity with its purpose and its model, rather than being hidden inside a system description. Exposure avoided: Sec. 10 duties carry up to ₹150 Cr, and SDF status is notified by the Central Government by class — an enterprise can acquire algorithmic due-diligence obligations without changing a line of its own code. ======================================================================== 6. DPDP BY INDUSTRY ======================================================================== ------------------------------------------------------------------------ DPDP FOR BANKING, FINANCIAL SERVICES AND INSURANCE ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/banking-and-insurance Sector: Banking & Insurance Regulators already involved: RBI, SEBI, IRDAI, NPCI, CERT-In BFSI holds the densest concentration of personal and financial data in the country, collects it across the widest channel mix, and shares it with the longest processor chain. Every one of those is a DPDP pressure point. Pressure points: Consent across assisted and paper channels (Sec. 6(1), 6(4)) Branch, agent, IVR, DSA and paper forms all collect personal data, and consent captured on paper still has to be specific, informed and withdrawable as easily as it was given. A digital-only consent stack leaves the assisted channels unevidenced. Processor liability down a long chain (Sec. 8(1)–(2)) Card networks, KYC vendors, collection agencies, analytics providers and cloud processors all inherit personal data. The Fiduciary carries the penalty for each of their failures, so the register has to map vendor to purpose to the consent that permits it. Retention against regulatory minimums (Sec. 8(7)) Sectoral rules require records to be kept for years; DPDP requires erasure once the purpose ends. Both are satisfiable, but only where the retention basis is recorded per attribute rather than applied as a blanket policy. Breach intimation inside the window (Sec. 8(6)) Scoping an incident to affected Principals across core banking, CRM, data warehouse and partner systems is the step that overruns. Without a catalogue it is an investigation; with one it is a query. Controls, in landing order: Consent Management -> Intelligent Data Mapper -> Privacy Program Governance -> Data Breach Management -> DSAR Management ------------------------------------------------------------------------ DPDP FOR HEALTHCARE AND HOSPITAL GROUPS ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/healthcare Sector: Healthcare Regulators already involved: MoHFW, NHA / ABDM, NMC, CDSCO, CERT-In Health data attracts the closest scrutiny under the Act, and hospital estates are unusually fragmented — HIS, LIS, PACS, pharmacy, insurance desk and teleconsultation platforms each hold a copy of the same patient. Pressure points: Consent at the point of care (Sec. 5, 6(1)) Consent taken at admission has to cover the purposes it is later relied on for — treatment, insurance claim, research, marketing — and be separable. A single admission-form tick cannot carry all of them. ABHA and health-record access (Sec. 8(4)–(5)) Linking records to a health ID broadens who can reach them. Access control has to be continuous rather than login-only, because shared clinical credentials are the most common route to unauthorised processing. Children's data and guardian consent (Sec. 9) Paediatric records require verifiable guardian consent, and the ban on behavioural advertising directed at children reaches any downstream marketing use of that data. Erasure against clinical retention (Sec. 8(7)) Clinical records carry statutory retention; the marketing and analytics copies of the same patient do not. Erasure has to distinguish them, which requires knowing every copy exists. Controls, in landing order: Consent Management -> Intelligent Data Mapper -> Data Anonymization & Masking -> DSAR Management -> Data Breach Management ------------------------------------------------------------------------ DPDP FOR GOVERNMENT AND PUBLIC-SECTOR BODIES ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/governance-risk Sector: Governance & Risk Regulators already involved: MeitY, CERT-In, Data Protection Board, CAG State instrumentalities carry exemptions in some directions and heightened scrutiny in others. The practical question is rarely whether an exemption applies — it is whether the body can evidence which one it relied on, and when. Pressure points: Exemptions have to be evidenced, not assumed (Sec. 7, 17) Processing for subsidies, benefits, services, certificates, licences and permits is a listed legitimate use. Relying on it without recording the basis per activity turns a lawful position into an undocumented gap at inquiry. Algorithmic due diligence on public systems (Sec. 10(2)(c)(iii)) Automated decisioning that affects entitlement carries the heaviest justification burden. Model purpose, training-data provenance, bias testing and human oversight all have to be on record. Notice in scheduled languages (Sec. 5) Public-facing services reach citizens who are entitled to notice in any of the twenty-two Eighth Schedule languages. Serving English alone is a defect in the notice itself, not a translation backlog. Records production under inquiry (Sec. 28) The Board may require production of records. For a public body the evidence trail is also the audit trail the CAG and the legislature will ask for. Controls, in landing order: Privacy Program Governance -> PIA / DPIA Assessment -> Audit & Evidence Management -> Intelligent Data Mapper ------------------------------------------------------------------------ DPDP FOR TELECOM OPERATORS AND HANDSET OEMS ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/alliance-with-mobile-phone-companies Sector: Telecom & Handset OEMs Regulators already involved: TRAI, DoT, MeitY, CERT-In Telcos sit on subscriber data, location, device identifiers and CDRs, and distribute through a retailer network they do not directly employ. The consent surface is wider than the systems that record it. Pressure points: Consent captured at the retail counter (Sec. 6(1), 6(4)) Activation happens through distributors and retailers. Consent taken there has to be specific and evidenced, and withdrawal has to reach the same systems that activation did. Location and device data as personal data (Sec. 4, 8(7)) Identifiers and location resolve to an individual, so they carry the same notice, purpose-limitation and erasure duties as name and address — including where they feed analytics products. Value-added services and third-party sharing (Sec. 8(1)–(2)) VAS partners and advertising platforms inherit subscriber data under the operator's Fiduciary liability, which makes the processor register a commercial control, not just a compliance artefact. Controls, in landing order: Consent Management -> Privacy Program Governance -> Intelligent Data Mapper -> DSAR Management ------------------------------------------------------------------------ DPDP FOR UNIVERSITIES AND EDUCATION PROVIDERS ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/educational-institutions Sector: Education Regulators already involved: UGC, AICTE, CBSE / state boards, MeitY Education providers process the data of minors at scale, retain it for decades, and share it with examination bodies, placement partners and edtech platforms — the combination the Act treats most cautiously. Pressure points: Verifiable guardian consent for under-18s (Sec. 9) School and undergraduate intake routinely involves minors. Guardian consent must be verifiable, and tracking or behavioural advertising directed at those students is prohibited outright. Alumni retention and purpose drift (Sec. 6(1), 8(7)) Student records are retained indefinitely and re-used for fundraising and marketing — purposes the original consent did not cover. Purpose drift is the most common defect in this sector. Edtech and proctoring processors (Sec. 8(1)–(2)) LMS, proctoring and analytics vendors process student data on the institution's behalf, and the institution carries the liability for them. Controls, in landing order: Consent Management -> DSAR Management -> Intelligent Data Mapper -> Privacy Program Governance ------------------------------------------------------------------------ DPDP FOR LARGE ENTERPRISES AND CONGLOMERATES ------------------------------------------------------------------------ URL: https://faceoff.world/dpdp/large-institutions Sector: Large Institutions Regulators already involved: MeitY, CERT-In, sector regulators per entity Group structures multiply every obligation: multiple legal entities, shared services, a common CRM and cross-entity data flows that were never modelled as transfers between separate Fiduciaries. Pressure points: Which entity is the Fiduciary? (Sec. 2(i), 4) Shared platforms across group companies make the determining party ambiguous. The Act attaches duties to whoever determines purpose and means, so the answer has to be recorded per processing activity rather than assumed from the org chart. Cross-entity sharing is sharing (Sec. 8(3), 11) Moving personal data between group companies is disclosure to another Fiduciary, with the notice and lawful-basis consequences that follow. SDF notification by class (Sec. 10) Volume and sensitivity make large groups the most likely candidates for Significant Data Fiduciary notification, which switches on DPO, auditor, DPIA and algorithmic duties on a government timetable rather than yours. Controls, in landing order: Privacy Program Governance -> Intelligent Data Mapper -> PIA / DPIA Assessment -> Audit & Evidence Management -> DSAR Management ======================================================================== 7. READINESS SEQUENCE ======================================================================== Phase 1 (Weeks 1–6) — See the estate - Deploy Discovery across priority systems - Build the identity-resolved catalogue - Reconcile collected data against notice - Stand up the processor register Products: Intelligent Data Mapper, Privacy Program Governance Phase 2 (Weeks 4–12) — Stop the bleeding - Mask non-production and analytics estates - Deploy breach detection and playbooks - Wire intimation to the catalogue - Evidence safeguards continuously Products: Data Anonymization & Masking, Data Breach Management Phase 3 (Weeks 8–18) — Fix the basis - Roll out purpose-level consent and notice - Enforce withdrawal parity and cessation - Turn on children's age-band gating - Migrate legacy consent where valid Products: Consent Management, Cookie Compliance Phase 4 (Weeks 14–26) — Prove it - Automate DSAR intake and fulfilment - Run DPIA cadence for SDF duties - Open the auditor workspace - Report posture to the board Products: DSAR Management, PIA / DPIA Assessment, Audit & Evidence Management Why this order: Discovery comes first because every other obligation is undeliverable without the catalogue. Masking and breach detection come second because Sec. 8(5) and 8(6) carry ₹250 Cr and ₹200 Cr — the largest exposure buys down earliest. Consent follows because it is the longest change-management effort and depends on knowing what is actually collected. Rights and audit come last because they consume what the first three phases built. ======================================================================== 8. FREQUENTLY ASKED QUESTIONS ======================================================================== Q: What is the DPDP Act, 2023? A: The Digital Personal Data Protection Act, 2023 is India's data protection law. It governs how organisations — Data Fiduciaries — may process the digital personal data of individuals, called Data Principals. It requires a lawful purpose, itemised notice, specific and informed consent, security safeguards, breach intimation, and a defined set of rights including access, correction, erasure and grievance redressal. Q: When is the DPDP compliance deadline? A: The DPDP Rules were notified on 13 November 2025, and full compliance is required by 13 May 2027. The Data Protection Board and its complaint mechanism are already operational, and Consent Manager registration is expected to open around November 2026. Most enterprise programmes take 9 to 12 months from gap assessment to audit readiness. Q: What are the penalties under the DPDP Act? A: The Schedule sets penalties of up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore for failing to intimate a personal data breach, up to ₹200 crore for children's-data failures, up to ₹150 crore for a Significant Data Fiduciary that misses its Section 10 duties, and up to ₹50 crore for other contraventions. Penalties are assessed per instance. Q: Who is a Significant Data Fiduciary? A: The Central Government may notify any Data Fiduciary, or a class of them, as Significant based on the volume and sensitivity of the data processed and the risk to Data Principals. An SDF must appoint a Data Protection Officer based in India who is answerable to the board, appoint an independent data auditor, and carry out periodic Data Protection Impact Assessments, audits and due diligence of algorithmic software. An enterprise can become an SDF without changing anything it does. Q: What is a Consent Manager under the DPDP Act? A: A Consent Manager is a registered intermediary that gives a Data Principal a single accessible, transparent and interoperable point to give, review and withdraw consent across multiple Data Fiduciaries. Registration is with the Data Protection Board and carries a minimum net-worth requirement. It is distinct from a Consent Management Platform, which is the software an organisation runs internally to capture and enforce consent. Q: Does the DPDP Act require consent for cookies? A: The Act requires consent by clear affirmative action before processing begins. In practice that means non-essential cookies and trackers must not fire until the visitor has opted in — prior blocking — with rejection as easy as acceptance and no pre-ticked boxes. A tag that fires before the affirmative action is unlawful processing from the first pageview, and no consent receipt recorded afterwards can retrofit it. Q: How long do we have to respond to a DSAR? A: The Act gives Data Principals rights of access, correction, completion, updating, erasure, grievance redressal and nomination, and requires a response within the prescribed period. Meeting that clock at volume depends on being able to locate every store holding a given individual's data, which is why a live data catalogue is a prerequisite rather than a nice-to-have. Q: How does DPDP compare to GDPR? A: Both require a lawful basis, notice, security safeguards, breach reporting and individual rights, so a mature GDPR programme covers much of the ground. DPDP differs in important ways: consent is the primary basis with a narrower set of legitimate uses, notice must be available in English or any of the 22 Eighth Schedule languages, verifiable parental consent is required for children with a ban on behavioural advertising directed at them, and the Consent Manager is a registered intermediary with no direct GDPR equivalent. ======================================================================== CONTACT ======================================================================== Enquiries: connect@faceoff.world Web: https://faceoff.world/contact