How we built a repeatable DPDPA engineering audit
The law was only half the problem. The other half was making every finding reproducible.
How a 49-check DPDPA skill turns legal duties into repeatable, evidence-backed engineering work.
A compliance answer that cannot show what it inspected is just a confident opinion. Our first DPDPA reviews had the right legal questions, but the output could drift with the model and the repository. The open-source skill now behaves more like a test suite: stable IDs, scoped evidence, dated sources, and an explicit status for work that is not yet in force.
First, pin what the law says now
The legal baseline is not one PDF. The skill pins the DPDP Act 2023, the final DPDP Rules 2025, the December 2025 corrigendum, the commencement notification, and known Board notices. We also reviewed the official MeitY Rules hub before release because a hash checker cannot discover a new notification at a new URL.
The commencement notification changed the shape of the audit. Definitions, Board provisions, and selected miscellaneous sections are in force. The Consent Manager provision and one Board power follow the one-year phase. Most product-facing duties, including notice, consent, security safeguards, children's data, rights, retention, and transfers, follow the eighteen-month phase.
Every report now starts with an audit date, source baseline, mode, and phase basis. A missing future-phase control is a readiness gap. It is not labelled as a current violation.
Build a checklist that does not drift
We turned the legal map into 49 checks across 10 dimensions, labelled A1 through J5. The IDs stay stable when the wording improves, so two audits of the same system can be compared without matching prose by hand.
The skill also includes 13 artifact specifications for the policies and operating records that code alone cannot prove. They are specifications, not a stack of generic templates to paste into a product.
Evidence comes before the verdict
Each finding must carry six things: a fixed ID, the legal requirement, status, severity, evidence, and a specific fix. A code finding cites file and line. A repository-wide absence can say `not found` only after a scoped search. A control that may live in operations, contracts, or another system stays `Needs review` until a person confirms it.
| ID | Requirement | Status | Severity | Evidence | Fix |
| C1 | Security safeguards, section 8(5) and Rule 6 | Readiness gap | Critical | api/db.ts:14 | Enforce TLS, move secrets, encrypt at rest |This rule prevents a common failure mode: treating grep as legal discovery. Search can show that a control exists. It can sometimes show that a risky pattern exists. It cannot prove that an off-repository process is absent.
Status and severity are different fields
Status answers: is the requirement applicable, in force on the audit date, and supported by evidence? Severity answers: how serious would the gap be if applicable?
That means a security control can be a critical readiness gap. The label preserves the potential impact without claiming a current breach. The penalty schedule helps order work, but a statutory maximum is not a prediction of what the Board would impose.
The skill supports two modes. Current-obligation mode scores duties in force on the audit date. Full-readiness mode evaluates notified future-phase duties too and labels them separately. If the team does not choose, we use full readiness because engineering changes take time.
Source drift now fails closed
The skill checks 13 known sources. Stable documents use SHA-256. Four secondary HTML pages sit behind a JavaScript challenge, so automation checks that they remain reachable and maintainers review the rendered pages. The Python checker returns 0 when every check passes, 1 when a source changed, and 2 when the check is incomplete. Matching source checks still do not replace the manual MeitY hub review needed to find new notifications at new URLs.
The limit is simple: the checker knows only the URLs already in the lock file. A maintainer still reviews the official MeitY hub for new notifications, then updates the legal references before re-pinning a changed source.
One playbook, thin host wrappers
The law, checklist, evidence patterns, and report contract live in one canonical skill. Claude Code, Codex, ChatGPT, and Hermes load that same bundle. No host carries a second copy of the legal corpus.
Version 2 also renames `dpdp-india` to `dpdpa-india`. That breaks old package paths and command names, so the migration is explicit instead of being hidden inside a minor release.
Why we made the source public
The checklist should be inspectable. The public repository now contains the source, install steps, legal references, and maintenance workflow. The DPDPA audit page explains the workflow and lets a team ask GattyWorks to audit a project.
What version 2 contains
- 49 stable checks across 10 dimensions
- A fixed report contract with current gap, readiness gap, compliant, needs review, and N/A statuses
- 13 policy and operational artifact specifications
- One canonical playbook for Claude Code, Codex, ChatGPT, and Hermes
- Pinned primary sources with fail-closed drift checks
- A migration path from the v1 names and report shape
- Release gates for legal discovery, owner approval, sample audits, and clean-install verification
The next test is deliberately boring
We will run the same audit against the same build after fixes and check whether the same IDs close. If the findings change names, disappear without evidence, or turn a future duty into a current violation, the system has failed even if the prose sounds good.
That repeat run is the point. A compliance review becomes useful engineering work when another person can inspect the evidence, challenge the status, apply the fix, and get the same result next time.