Chapter 22 — Control Testing, Audit Evidence and Effectiveness

1. The word that keeps the book honest

Section 8(4) requires appropriate technical and organisational measures to ensure effective observance; Section 8(5) requires reasonable security safeguards to prevent personal-data breach (ACT:343–347).[1] Neither provision says one passing adversarial test establishes compliance. Section 10(2)(b) requires an independent auditor for the SDF; Section 33(2)(e) makes the timeliness and effectiveness of mitigation relevant to penalty assessment, not a formula for reducing or doubling a fine (ACT:427–429,827–846).[1]

The useful implementation chain is obligation → control → test → evidence → review. Each link asks a different question. Does the obligation apply? Is the control appropriately designed? Did the observed execution meet the criterion? Does the evidence support the claimed scope? A test can be correct while the legal mapping, population coverage or production configuration is wrong.

2. The tension: cost of testing versus cost of an unproven control

The tension surfaces whenever budget holders ask, “Why spend on a test that never sells?” The two pulls are:

• Cost‑of‑testing pull. Building fixtures, seeding environments, running drills, storing artefacts, and re‑running on every change consumes engineering cycles that could be used for product features. The temptation is to replace a test with a policy document, a checklist, or a signed declaration.
• Cost of an unexamined control. An untested design can conceal a harmful bypass. Investigation and remediation may then be harder because neither the behaviour nor the evidence boundary was understood. The penalty outcome remains a legal determination under Section 33, not the automatic full Schedule ceiling or a doubled fine (ACT:827–846).[1]

The failure modes are well known:

• Shelf‑control. Documented but never exercised – e.g., a deletion policy that has never survived a restore‑orphan fixture.
• Endless‑test. Over‑testing low‑risk rows while high‑risk obligations sit uncovered, draining the assurance budget.

Proportional testing balances harm, exposure, population reach, change frequency and uncertainty. Penalty ceilings can inform prioritisation but do not rank all principal harms or permit omission of an applicable duty. Reusable fixtures reduce repeated setup; evidence ownership makes their limitations and maintenance visible in the Chapter 24 budget.

3. The obligation → control → test → evidence grid

Every applicable obligation needs a mapping to controls and evidence, but not every obligation is a software assertion. Appointment, independence, legal scope and actual notification require human or external evidence. The following is a recommended mapping, not a statutory test catalogue.

These mappings draw on ACT:206–268,338–359,386–487 and RULES:1087–1166,1269–1323.[1][5] The source paths and newline ranges are retained in the packet. The control column is an author design. A scope omission or misread exception can invalidate a green result, which is why the legal mapping is reviewed before a fixture is adopted.

4. The reusable test catalogue

The supplied catalogue in out/templates/tests/README.md identifies implemented tests and proposed integration families separately. Compliance regression reruns the bounded model after changes. Rights simulations compare against explicitly chosen internal targets, not an SLA invented from Section 11. The statutory grievance rule requires a prominently published reasonable response period not exceeding ninety days and supporting measures; it is not a general access/correction/erasure deadline (RULES:1294–1318; ACT:441–487).[5][1]

The core families remain:

• Positive. Happy path runs – lawful processing works.
• Negative. Unlawful use is denied – no ground, no purpose.
• Race. Concurrent operations – erasure racing access, withdrawal during a breach.
• Restore/orphan. Backup restore does not resurrect erased data.
• Processor. Partial failure across the processor chain.
• Adversarial. Injected malicious inputs, stale grants, service‑principal drift.

Each fixture specifies:

1. Setup. Data set, environment, configuration.
2. Action. Trigger the control.
3. Observation. Expected logs, receipts, or state changes.
4. Pass/Fail. Exact condition (e.g., checksum matches, timestamp < SLA).

out/templates/tests/ now contains the sequential teaching model, unit/negative tests and sampling calculator. It does not contain a load generator, deployed consent service, SIEM integration or a complete statutory fixture engine. The blank engineering template remains useful for production workpapers; it is not itself execution evidence.

5. Expanded statutory anchors, assembled

Keep a source version beside each legal test. Rule 14 is a rights rule, not an evidence-retention rule. Rule 15 concerns Government-specified requirements for data made available to a foreign State or controlled entity/agency, not a mandatory transfer provenance-tag schema (RULES:1294–1323).[5] The book recommends recording route, location, decision and applicable restriction for transfer assurance; no future amendment or statutory JSON tag is asserted.

Retention needs its own applicability decision. Rule 6(1)(e) addresses security-purpose logs and personal data for one year unless law requires otherwise. Rule 8(3) separately requires minimum one-year retention from processing for Seventh Schedule purposes, followed by erasure subject to further lawful/notified retention. Sections 8(7) and 12(3) contain their respective retention qualifications (RULES:1101–1104,1153–1166; ACT:351–359,473–476).[5][1] Data minimisation therefore does not mean immediately purging all evidence after withdrawal. Nor does audit convenience justify indefinite identifiable retention. Classify purpose, access, clock, later processing, hold and disposal eligibility as Chapter 14 explains; pseudonymisation does not automatically remove personal-data obligations.

Rule 13 supplies the SDF assessment/audit twelve-month cycle, significant-observations reporting, technical-measure diligence and conditional specified-data restrictions (RULES:1276–1293).[5] An automated suite is supporting evidence, not the independent auditor or the report-furnishing act.

6. Governance and reporting integration

Three recommended governance links make the grid usable. First, dashboards show tested scope, first-run failures, unresolved mandatory controls and evidence age, not merely an aggregate pass rate. Second, defects have a harm-based priority, owner, restricted operation and retest condition. Third, a human-reviewed regulatory-change process reopens affected mappings before new tests are declared authoritative. No Gazette RSS parser or automatic legal interpretation service is supplied here.

The system should preserve initial failure and later retest separately. Deleting a red run after repair misrepresents the operating history; retaining a stale green run after a release misrepresents current scope. A reviewer needs both configuration identity and test time. A passing subset must never clear an untested mandatory path.

7. Evidence sampling methodology

Sampling estimates a declared property under assumptions; it does not confer legal permission for a defect rate. No retained provision supplies the chapter’s former “statutory representativeness” or zero-defect confidence formula. Critical known failure paths should be exercised directly and fixed, not hidden within a random average.

The supplied evidence_sampling.yaml uses JSON syntax, a valid YAML subset, so the stdlib calculator needs no YAML dependency. It specifies a hypothetical independent Bernoulli model, alpha 0.05, proposed defect bound 0.01 and zero observed defects. For n independent, identically distributed trials with defect probability p, the probability of observing none is (1−p)^n. Solving (1−p)^n = alpha yields the one-sided zero-event upper confidence bound p_upper = 1−alpha^(1/n). The minimum n for p_upper ≤ p_target is ceil(log(alpha)/log(1−p_target)). These are mathematical design assumptions, not DPDP thresholds.

For these hypothetical parameters, the calculator determines n and the boundary immediately below n; the recorded output shows why rounding down fails. Even zero defects in a finite sample leaves a strictly positive upper bound. No finite n establishes a population defect rate below zero. If defects are observed, this zero-event calculator refuses to issue its bound; it does not silently apply the wrong formula.

The model is not appropriate for an arbitrary convenience sample, duplicated transactions or correlated processor batches. A finite population sampled without replacement requires a different design; a seeded hash selector is reproducible but not by itself proof of random selection or independence. Define the population, frame, unit, period, exclusions, selection mechanism and missing outcomes before sampling. Keep separate strata for important paths rather than claiming a pooled average protects every group. A census of available logs still misses events the logging system failed to capture.

The calculator generates a proposed sample size, not actual transactions or observed audit results. Its tests cover invalid rates, zero/non-integer sample sizes, nonzero defects and the rounding boundary. It deliberately does not implement Wilson intervals, stratified selection, power analysis or automatic population discovery. A reviewer adapting it must justify the assumptions and treat legal failures as failures even when a statistical bound would appear acceptable.

8. Test vs. audit evidence

Test evidence is an observation plus context: setup, version, action, expected outcome, actual result and limitations. A digest helps identify the file later; it cannot prove that the test covered the right behaviour or that an external acknowledgement is truthful. Audit evidence adds the reviewer’s work, population coverage, judgments and qualifications. For an SDF, the auditor’s independent evaluation is a distinct duty, not a label the delivery owner can add to a test log (ACT:427–429).[1]

Use separate raw and reviewed layers if useful, but give each a purpose/access/retention decision rather than retaining reviewed material for a whole control lifecycle by default. Review often can use aggregate or redacted evidence; when identifying data is necessary, document the reason and applicable Rule 6/Rule 8 retention class. Later audit value is not an unlimited retention rule (RULES:1101–1104,1153–1166).[5]

A completed workpaper also names what was not observed: processor internals, backup destruction, authentic signatures or network effects. A mock can verify an interface contract but cannot prove delivery to a real recipient. This distinction matters more than the number of hashes in the evidence store.

9. Metrics for testing effectiveness

Use the following author-recommended management indicators without making them legal safe harbours.

The dashboard should retain denominators, excluded records and clocks. A reduction in simulated latency is not measured production improvement. A test pass rate is not breach probability, and multiplying its complement by a Schedule ceiling produces no defensible expected monetary exposure. Section 33(2)(e) names mitigation action and its timeliness/effectiveness, not an assurance-score discount (ACT:841–846).[1]

10. A completed local failure/remediation/retest packet

Scope. out/templates/tests/run_packet.py exercises an explicitly synthetic sequential model on CASE-001 identities. It does not impersonate a processor, contact a regulator or claim a deployed control. out/remediation/Q05/failure-retest-results.json records actual local observations; expected values are stored alongside, not presented as observations before execution.

Setup and action. A teaching legacy gate is seeded with an active PUR-002 marketing grant. WITHDRAW-001 is accepted. The defective version leaves its cached allow unchanged, so a subsequent marketing request is incorrectly allowed. The assertion records a failed control outcome. The fixed version checks current purpose-specific state and denies the request. It also rejects an old grant replay after the withdrawal sequence. The defect is intentionally injected to demonstrate how evidence survives remediation; it is not a discovered production defect.

Propagation and retention. ENT-004’s acknowledgement is deliberately missing at the scenario’s illustrative five-minute target. The model reports pending propagation; it must not turn local denial into complete processor cessation or erasure. Adding a synthetic acknowledgement closes only that tested action. A separate retention case keeps a restricted copy under stipulated reviewed legal-minimum facts while denying active marketing. The output’s meaning is conditional behaviour, not proof of actual lawful retention, authenticated supplier deletion or a complete backup inventory.

Decision. An implementation owner may use the retest to close the specific model defect. The full enterprise control remains unassessed because its integrations, concurrency and actual scope are absent. The report keeps first-run failure, remediation description and retest values in one packet. A reviewer can reproduce it with python out/templates/tests/run_packet.py from the book root.

Additional integration specifications, not claimed results

A real processor test would need signed/otherwise authenticated acknowledgements, complete target enumeration, actual effect evidence and late/replayed response handling. An unauthorised-sharing test would need network observation at all egress paths, not just a mocked return. A malformed-token test would need a real verifier; the local model does not implement JWT signatures. A cryptographic-library regression would need the changed binary and meaningful log/key checks. No such deployments are claimed here.

Likewise, a high-volume rights simulation needs actual arrivals, service times, retries, identity/exception branches and a load-capable environment. The former two-million-case insurance example and 96%-then-100% latency results were unsupported and are not retained as telemetry. Chapter 24 instead supplies a hypothetical workload model; that arithmetic is not a latency benchmark. If a buyer chooses a 72-hour internal response target, label it internal, explain how compound cases and clock starts are handled, and do not attribute it to Section 11(1)(c) (ACT:441–476; RULES:1294–1318).[1][5]

11. What remains for the reader and the reviewer

The local package settles its narrow deliverable promise: executable fixtures, sampling calculation and a retained failure/retest workpaper. It does not settle what evidence a Board inquiry will find sufficient, complete coverage of an enterprise’s register, or a particular audit opinion. The Rule 13 cadence and Rule 15 wording have been read and mapped; no pending amendment is invented to defer them. Production integration, independence and source-update review remain application requirements, not missing local outputs.

The question that hands the book its next chapter

Testing supports a scoped control judgment; maintaining that judgment requires change and delivery discipline. Chapter 23 addresses the plan, migration and BAU handoff without turning a green fixture into universal demonstrated compliance.

References (sources retained)

• DPDP Act 2023 — research/legal/evidence/01_dpdp_act_2023_gazette.txt (Sections 8, 10, 33).
• DPDP Rules 2025 (GSR 846(E)) — research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt (Rule 13, Rule 14, Rule 15).
• Blank engineering workpaper — out/templates/engineering/ENGINEERING_EVIDENCE_TEMPLATE.md.
• Chapters 6 (scenario bands), 17 (evidence tiers), 19/20 (independent audit), 24 (budget), 36 (re‑verification rhythm).

Source keys and evidence limits

Line locators use newline-based retained text, not PDF page numbers. Primary sources were reread locally; no complete live legal-update search or entity-specific opinion is asserted. Vendor passages are documented claims, not observed capabilities.

• 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.
• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index