Chapter 8 — Purpose, Necessity and Processing-Ground Governance

1. The master key

Several controls depend on a shared purpose definition. Notice identifies the purpose; consent is limited to necessary data for it; withdrawal reverses the relevant grant; and the deemed-purpose mechanism has its own statutory conditions (ACT:167–175,206–209,232–249,369–385).[1] The erasure duty (Section 8(7)) has an earlier-event trigger and lawful-retention qualification (ACT:351–375).[1] Even the child rules (Chapter 13) and the model registry (Chapter 21) borrow the word: processing needs a purpose, and the purpose must be lawful and grounded.

Purpose and ground are separate attributes. Purpose says what an activity is trying to accomplish; ground records why the processing is authorised. An author-recommended matrix joins them to datasets, recipients and evidence. Every materially new use receives a review, but review may confirm an existing ground rather than necessarily inventing another one. An unapproved purpose remains blocked even when the same dataset supports another approved activity.

2. The statutory frame, read as a gate and two doors

The gate: Section 4. Personal data may be processed “only in accordance with the provisions of this Act and for a lawful purpose” — and Section 4(2) defines lawful purpose with disarming economy: any purpose which is not expressly forbidden by law. The gate is wide, but it is a gate: purpose legality is checked, and then the ground must carry the processing through consent or certain legitimate uses, subject to the Act’s scope and exemption architecture (ACT:160–166).[1]

The gate’s width is its own trap. Because “not expressly forbidden” is a low bar, the temptation is to treat it as the only bar — to reason that if a purpose is lawful, the ground is a formality. It is not. The gate permits the purpose; the ground authorises the processing. An enterprise that stops at the gate and never walks through a door has documented the purpose’s legality but has no authority to process.

Door one: consent (Section 6). Free, specific, informed, unconditional, unambiguous, by clear affirmative action, limited to the specified purpose and the necessary data (Chapter 9 builds the evidence chain). It is not automatically preferable to a genuinely applicable Section 7 clause, and a checkbox does not repair missing freedom, necessity or specificity (ACT:206–231).[1]

Door two: certain legitimate uses (Section 7). The following complete (a)–(i) navigation matrix paraphrases primary text; it does not quote invented limbs. The proposed approvers and evidence records are author recommendations, not named statutory offices (ACT:269–329).[1]

For Section 7(b), Rule 5 defines the law/policy/public-funds routes and the Second Schedule requires lawful, purpose-limited, necessary processing, reasonable accuracy efforts, scoped retention, safeguards, intimation/contact/rights links and accountability. A clause label without these applicable conditions is incomplete (RULES:1064–1084,1553–1595).[3] Do not import a universal necessity word into each clause’s exact wording; use minimisation as an expressly recommended control alongside the clause’s actual conditions.

The central boundary from Chapter 3 remains:

DPDP has no “legitimate interest” ground. The GDPR practitioner’s familiar sixth basis — the balancing memo that justified a decade of behavioural processing — is not a standalone DPDP ground. Where the Act applies without an applicable exemption, a balancing memo alone does not authorise processing; identify consent or a matched Section 7 clause (ACT:160–166,269–329).[1]

3. The tension: the utility of reuse versus the two-grounds discipline

Reuse creates a review question, not an automatic change of legal ground. A repeated payment acknowledgement within an unchanged valid Section 7(a) request can remain on the same clause. Training a model on lending transcripts is a materially different purpose whose authority cannot be inferred from their availability.

The reuse pull. The data is right there. The order history could power the recommendation model; the support transcripts could train the chatbot; the employee data could benchmark the product. Collection is sunk cost; reuse is near-free; and the entire modern data economy is built on the premise that yesterday’s collection is tomorrow’s feature. The pull is not greed — it is the ordinary instinct of every analyst, product manager, and founder who has ever looked at a full warehouse.

For example, voluntarily provided contact details and a requested receipt can satisfy Section 7(a) on their documented facts. That does not license unsolicited marketing. Where new processing lies outside an existing consent or clause, obtain valid separate authority or stop; no general legitimate-interest balancing route supplies the missing permission (ACT:160–166,271–284).[1]

The failure modes, named:

• The GDPR transplant, again, because it keeps happening: the legitimate-interests memo pasted into an Indian ground column. Worth nothing here.
• The silent reuse — the warehouse’s gravity doing the deciding: data collected for one purpose quietly feeding another, no decision ever taken, no notice ever given, the violation distributed across a hundred dashboards until it looks like architecture.
• The over-read legitimate use — stretching Section 7’s clauses past their language: “employment” covering a wellness product’s marketing; “safeguarding the employer” covering an unrelated analytics build. The clauses are bounded; the bounding is the work.
• The necessity gap — a purpose that is technically grounded (on consent, even) but collects more data than the purpose requires. Section 6(1)‘s “limited to such personal data as is necessary” is not aspirational; it is a statutory ceiling on the data scope, and the necessity column in the matrix is where it is enforced.

The matrix is a decision queue: allow with evidence, condition pending specified facts, stop, or retire. “Conditional” must not translate to an allow token. A missing approver or absent evidence keeps the disputed operation out of the release path.

4. The purpose/data/ground control matrix

The useful grain is dataset × activity/flow × purpose × affected subject group, not one ground for a whole system. GROUND-001 is a completed synthetic decision set in out/remediation/Q03/purpose-decisions.json; the following are its reader-facing rows. Each has the frozen source version, owner, necessary-data scope and hypothetical commencement assumption.

Three columns deserve their design explained, because they carry the chapter’s discipline:

The ground column names the clause. Not “legitimate use” — which clause, by number and limb. The named clause is what counsel can review, what the runtime can enforce, and what an inquiry can test. The unnamed clause is where over-reading hides.

The necessity note is per element. Section 6(1) bounds consent “to such personal data as is necessary for such specified purpose” — and the Act’s own telemedicine illustration (phone contacts are not necessary for telemedicine) shows the bounding is meant seriously. The necessary-data condition and phone-contact illustration are in ACT:206–215.[1] The necessity note records the rejected over-collection. The The receipt row demonstrates a necessary contact field without making its scope transferable to unrelated advertising. A delivery-location ping would need its own collection and purpose facts; a notice alone would not establish Section 7(a).

The status column has a flag state. The unsupported-reuse flag is not an annual audit finding — it is a live state the runtime enforces (below) and the Chapter 24 dashboard counts. An enterprise’s number of open flags is its honest reuse-debt metric.

5. Governance: the operating process around the matrix

Purpose approval. A new activity enters through a named decision-maker, source-linked scope and ground facts. Consent requests need their notice before or with the request; do not imply Section 5 consent-request mechanics apply identically to every Section 7 use (ACT:167–175).[1]

Notice synchronisation. The purpose must match the live notice (Section 5/Rule 3) — and when the notice changes, the affected consents are re-checked (Chapter 9’s versioning), not silently grandfathered. A notice that adds a purpose without re-grounding the data for that purpose is a notice that describes an aspiration, not an authorisation.

Reuse review. Every secondary use passes the two-grounds test before its pipeline runs; the flag state exists precisely so that “we already have the data” is never the reason. The reuse review is not a annual gate; it is a live gate. In the proposed architecture, a data pipeline, analytics query or training job without a reviewed activity/purpose is denied and queued for review. This is a design specification, not a report of deployed enforcement.

Revalidation on change. The ground re-arms when data is combined (Section 2(x) counts combination as processing), when it flows to a new recipient, when an Section 7 condition changes, or when a sector overlay moves (Chapter 5). Grounds are not set-and-forget rows; they are re-verified state. The enterprise that grounded a processing activity on Section 7(i) for employment cannot silently use those records for an unrelated wellness-marketing campaign. The changed facts require a fresh review; a stored clause string is not continuing authority.

Purpose-completion. Mark actual purpose-end independently of Rule 8’s class-specific deemed inactivity. Feed the earlier withdrawal/purpose-end trigger to a separate retention/disposal decision; do not create a universal clock for all account closures. Third Schedule classes, excluded purposes, latest qualifying approach/rights event and the 48-hour warning matter, alongside the separate Rule 8(3) minimum (ACT:351–385; RULES:1142–1166,1598–1680).[1][3]

Necessity audit. The necessity column is not set once; it is audited when the purpose changes, when the data scope changes, and when the ground changes. A purpose that was necessary at collection may become unnecessary if the business model shifts; the matrix must capture that shift. The telemedicine illustration is not a one-time test — it is a standing discipline.

6. Enforcing purpose/ground at runtime

Documentation alone is a policy; the matrix earns its name when it is enforced — and the enforcement design is where the earlier chapters’ architecture pays:

This is an author-recommended runtime architecture, not a claim that the Act specifies tokens or policy engines. SYS-010 is the trusted purpose issuer. It authenticates the workload, binds a reviewed processing activity to a narrow purpose, dataset, subject scope and policy version, and consults current authority. SYS-001’s caller-supplied purpose_id is untrusted input; accepting a self-declared lawful purpose would defeat the matrix.

The enforcement point at each query/export/send verifies workload entitlement and issuer provenance, then checks current consent or clause conditions. A marketing worker cannot ask for a PUR-001 loan token to bypass WITHDRAW-001. Version changes invalidate stale cache decisions. Direct-store credentials, administrative exports, scheduled batch jobs and break-glass access must be separately restricted and logged; an API gate cannot prove that these bypasses do not exist.

Three proposed acceptance tests make the difference observable. A client-supplied PUR-001 tag without trusted issuance is denied; a legitimately issued old PUR-002 token after withdrawal is denied at the final send; and the same workload requesting PUR-003 receives DEC-001 stop, not a token. The local semantic fixture exercises these decisions with synthetic inputs; it is not an authentication implementation, distributed race test or proof of production bypass closure. Chapter 15 owns the broader safeguard design.

7. Two worked walkthroughs

Walkthrough one — contested training reuse. In CASE-001 the Company proposes to train its support assistant on DS-006. PUR-003 is not granted by CONSENT-001 for requested lending or by CONSENT-002 for marketing. DEC-001 therefore stops FLOW-003; no job starts. The ML owner may propose a narrower, genuinely de-identified corpus or seek a valid separate consent, but a proposal is not evidence that either route succeeds. Consent from one customer would not authorise another person’s data embedded in a transcript. Necessity, third-party content, security and model identifiability remain review items, rather than an invented campaign that instantly approves training.

A later consent could authorise a bounded future training activity without curing earlier unauthorised processing. Withdrawing training consent requires separate assessment of retained inputs, identifiable features and model artefacts; lineage alone cannot locate a person’s contribution inside weights or prove effective unlearning. Chapter 10 owns cessation coordination and Chapter 21 the derived-model assessment.

Walkthrough two — the alternate contact belongs to someone. A signup flow asks SUB-001 for an entire phone contact list to enable recovery. The necessity review rejects that bulk collection, but reducing it to one alternate contact is not enough. If it is SUB-001’s own second address, record that provenance and the relevant consent or clause conditions. If it belongs to another person, SUB-001 cannot supply that person’s consent merely by typing it. Voluntary provision by SUB-001 is not voluntary provision by the other principal under Section 7(a). No permission follows from the word “recovery”.

The proposed Q03-DEC-002 branch therefore rejects storage/use of another person’s recovery contact pending a separately evidenced route. Product chooses a recovery code held by the account owner instead, an author-designed alternative that avoids third-person contact collection. The example has a different outcome from the original one-contact approval because data quantity and authority answer different questions.

For a workshop, change only the provenance field from own contact to third-person contact while leaving the purpose text unchanged. The decision must change. Then change only the proposed reuse from receipt to marketing; the existing receipt authority must not expand. These counterfactuals expose whether the matrix actually encodes facts or merely decorates a preselected business outcome.

8. What remains for the reader and the reviewer

The open items, each <residual>:

1. Determine which clauses the real entity’s actual flows meet, especially unsuccessful applicants, monitoring and third-person data. Missing facts keep the activity unresolved, not approved.
2. Resolve entity-specific retention and scope issues through the canonical question register; the full Section 7 list and State-benefit conditions above are no longer unread work.
3. Implement and observe trusted issuance, workload identity, direct-store restrictions and race handling in the actual estate. The local checks only exercise the authored decision model.

The question that hands the book its next chapter

Each reviewed activity now has either an evidenced authority or an explicit stop. Chapter 9 takes the consent-based subset through an actual notice and affirmative-choice specimen, preserving that boundary instead of implying every inventory item was already authorised.

Evidence and reusable artifacts

The primary-text line keys ACT, COMM, RULES and CORR resolve to the retained files below. Line numbers count physical newlines, not PDF form feeds. The canonical provision register supplies actor, trigger, conditions, exceptions and effective dates; chapter recommendations and synthetic examples are not statutory forms. The Q03 source manifest preserves URL, retained retrieval metadata and recalculated hashes.

• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt
• COMM: research/legal/evidence/02_gsr_843e_commencement.txt
• RULES: research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt
• CORR: research/legal/evidence/06_gsr_892e_corrigendum.txt

Completed chapter fragments, before/after evidence and actual local checks: out/remediation/Q03/. Blank operating templates remain under research/operations/templates/; The reconciled integrated dossier is the reader working copy; these chapter fragments preserve the earlier bounded examples and their run evidence.

Blank companion: research/operations/templates/purpose-register-template.md; completed Q03 fragments retain the same decision boundaries.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — ACT [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — COMM [3] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — RULES [4] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — CORR

Contents · Reader guide and citation conventions · Artifact index