Compliance you can prove: engineering India's DPDP law into the infrastructure

The question that will be asked

Picture a personal data breach at an Indian company in the second half of 2027. Within seventy-two hours of becoming aware of it, the company must send the Data Protection Board a detailed account: what happened, how it happened, what has been done to contain it, who caused it, and what will stop it happening again (Rule 7(2) of the DPDP Rules, 2025). Affected customers must be told without delay (Rule 7(1)).

Every answer in that report depends on evidence. Who accessed the data, and when. Whether the logs that would show it still exist. Whether the access controls described in the security policy were actually in force on the day. Whether anyone could have switched off the audit trail before the attacker did.

A policy document cannot answer any of these questions. It can describe what was intended. Only the systems themselves can show what happened.

That is the gap this article is about, and the reason I am building DPDP in Practice: an open, working compliance system for India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, built on AWS, in public, release by release.

---

What the law actually asks for

The Act sets the duty. Section 8(5) requires a Data Fiduciary to protect personal data in its possession or under its control "by taking reasonable security safeguards to prevent personal data breach". Section 8(4) adds a broader duty to implement "appropriate technical and organisational measures to ensure effective observance" of the Act and the Rules.

The Rules then say what "reasonable security safeguards" must include, at the minimum. Rule 6(1) lists seven:

Two other provisions sit close to these. Rule 8(3) requires personal data, associated traffic data and logs of processing to be retained for a minimum of one year for the purposes set out in the Seventh Schedule. And Rule 7 sets the breach timeline described above.

The consequences are not abstract. Under the Schedule to the Act, failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore, and failing to notify a breach up to ₹200 crore. The main obligations, including Rules 6, 7 and 8, apply from 13 May 2027.

Read the list again with an engineer's eye. Encryption, access control, logging, monitoring, retention, backups, and measures that make all of it work in practice. Six of the seven clauses describe properties of systems. The seventh, Rule 6(1)(g), asks for proof that the other six actually operate. This is not a law that can be met in a document library.

---

Why paper compliance falls short

Most organisations will begin, sensibly, with policies: an information security policy, an access control policy, a logging standard, a retention schedule. These are necessary. They set intent, assign ownership and give auditors a reference point. The difficulty is what happens between the policy and the system.

Policies drift from reality. A logging standard says logs are kept for a year. Six months later, someone adds a lifecycle rule to reduce storage costs, and logs older than ninety days quietly disappear. Nothing in the policy changes. Nobody notices until the logs are needed.

Policies cannot stop the people who hold the keys. In most cloud environments, an administrator can delete the audit trail, change a bucket's retention, or grant themselves access to data. A policy that forbids this does not prevent it. When the person under investigation is the person with administrator rights, the written rule offers no protection at all.

Policies cannot produce evidence on demand. When the Board, an auditor or a customer asks whether a control worked on a given day, a policy can only say that it should have. Rule 6(1)(g) asks for safeguards that are "effectively observed". Effectiveness is shown, not stated.

None of this is a criticism of policy work. It is a recognition that, for this law, the policy is the beginning of compliance, not the end of it.

---

GRC engineering: from obligation to evidence

GRC engineering is the practice of turning governance, risk and compliance requirements into controls that are built into systems, tested automatically, and able to produce their own evidence. The approach I follow has four steps, applied to every legal duty:

1. Obligation. Start from the exact text of the law, not a summary of it. Each duty gets a stable identifier taken from the law itself, for example DPDP-Rule-6(1)(e).
2. Control. Decide what in the system makes the duty true, and build it as code: infrastructure definitions, policies, configuration and checks, all kept in version control.
3. Test. Write an automated test that tries to break the control, or confirms that it holds. If the law says logs cannot be erased, the test tries to erase them.
4. Evidence. Every test run stores a record of what was attempted, what the system replied, and whether the control held, in storage that nobody can alter afterwards.

The identifier travels through all four steps. A reviewer can start from a clause of Rule 6, find the code that implements it, run the test that proves it, and read the stored evidence. The same chain works in reverse: any piece of infrastructure can be traced back to the duty that justifies it.

The point of this is not automation for its own sake. It is that compliance becomes a property of the system that can be demonstrated at any time, rather than a claim that is reconstructed when someone asks.

---

DPDP in Practice: what is being built

DPDP in Practice applies this approach to the whole of the DPDP Act and Rules, using a fictional company, Fernleaf Finance, an Indian lender with a prepaid wallet. All of its data is synthetic. Everything is built on AWS in the Mumbai region, published as open source, and released in stages.

The first release, Release 0, was the blueprint: the DPDP Obligations Matrix, a workbook that sets out every duty in the Act and the Rules in 40 rows, accounts for all 83 provisions, and reproduces the exact Gazette text for each. Every later release takes a group of those duties and builds the controls, tests and evidence for them:

• Foundations and knowing what you hold: the cloud foundation, the personal data register, and logs that last
• Find and Prevent: comparing what the company actually holds with what its register says, and enforcing safeguards before a change is released
• Notice, consent and withdrawal, including parental consent and Consent Managers
• Retention and erasure, including what must be kept under other laws, and how it is sealed until its period ends
• Breach response, built around the seventy-two-hour report to the Board
• Rights, grievances and vendors
• Prove: showing that the measures work in practice, as Rule 6(1)(g) requires

Each release is published with its code and a guide that lets anyone reproduce it; from Release 1 onwards, also with its tests and the evidence they produce.

---

The thinking behind the architecture

Release 1 builds the foundation that every later release depends on. Each design decision starts from a question the law raises, rather than from a technology.

Question 1: who could alter the evidence?

If logs sit in the same AWS account as the data they record, anyone with administrator rights in that account can delete or change them. For Rule 6(1)(c) and 6(1)(e) to mean anything, the logs must be out of reach of the people and systems they are recording.

So the design separates duties into separate AWS accounts, grouped into organisational units:

Each account is its own security boundary. A mistake or a compromise in one does not reach the others. The law does not prescribe AWS accounts. It prescribes outcomes, and account separation is the most reliable way to achieve them on AWS.

Question 2: what should nobody be able to do, including administrators?

Some actions should be impossible, not merely forbidden. AWS Organizations provides service control policies: guardrails that set limits no one in a member account can exceed, however senior their role. Release 1 attaches four:

• Region. All activity outside the Mumbai region is denied. The DPDP Act does not itself require data to stay in India; Section 16 allows transfers unless the Government restricts a country. The restriction here reflects a sector rule instead: the Reserve Bank of India requires payment system data, such as Fernleaf's wallet records, to be stored only in India.
• Baseline. No account can leave the organisation, nobody can stop or alter the audit trail, and the root user cannot be used.
• Buckets. Nobody can delete, shorten the lock on, or weaken the log and evidence buckets.
• Cost. Expensive services and large servers are denied, so a mistake cannot become an expensive incident.

Each guardrail is attached first to the sandbox and tested there, then to the accounts that hold data and logs. A guardrail that has not been tested is a risk in its own right.

Question 3: how is access controlled and shown?

Rule 6(1)(b) requires control over access to computer resources. The design removes the most common weaknesses entirely rather than managing them:

• No stored keys. People sign in through a single identity service with multi-factor authentication and receive temporary credentials. No account contains users with permanent passwords or access keys.
• No root access. The root credentials of the member accounts are removed. The few tasks that need root are run centrally.
• Least privilege by role. Access is granted through defined roles. An auditor can read logs and evidence. A viewer can see which resources exist and how they are configured, but cannot read the personal data inside them. Administrator access exists for setup and emergencies only, in one-hour sessions, with every use recorded.

Question 4: how long do logs last, and can they be trusted?

An organisation-wide trail records every action in every account and writes it to the log archive account. There, the logs are locked with S3 Object Lock for one year, and the bucket guardrail stops anyone in the member accounts from deleting them, shortening the lock or switching off versioning. That is Rule 6(1)(c) and Rule 6(1)(e) expressed as configuration: the logs exist, they are kept for the period the law requires, and they can be trusted because nobody under review can change them.

Question 5: does the company know what it holds?

Many obligations, from notices to erasure, depend on knowing what personal data exists, where it is, why it is held and for how long. Release 1 keeps a personal data register as code. Every category of data must record a purpose, a legal basis, the store that holds it, a retention rule with its legal reason, and a contract clause for each vendor that receives it.

The register is checked automatically before every change. A data flow without a recorded legal basis stops the commit. The register is also compared with the live AWS account: any store tagged as holding personal data that the register does not know about is reported. A register that drifts from reality is worse than none, because it gives false assurance.

Question 6: how is it proven?

Release 1 ships fourteen tests. Some read files; most act against the real AWS accounts. Among them:

• An administrator of the log archive account tries to delete a log file, delete it by version, shorten its retention, suspend versioning, delete the bucket, and stop the trail. Every attempt must be refused.
• An engineer tries to create storage outside Mumbai. It must be refused.
• The accounts are checked for users with stored passwords or keys. There must be none.
• A data flow with no legal basis is added to the register. It must be blocked.
• One command must list everything held about a test customer, with Aadhaar and PAN masked.

Each test writes an evidence record: the control identifier, the time, what was attempted, the response from AWS, the outcome, the version of the test code, and a checksum. The record is stored under Object Lock in compliance mode, which means it cannot be altered or deleted during its retention period by anyone, including the account's own administrators.

How the safeguards map to the build

Clause (d) is not yet built, and the table says so. A compliance system that overstates its own coverage repeats the problem it is meant to solve.

---

What building in public has taught so far

Building openly means the practical lessons are visible as well as the results. A few from Release 1 are worth sharing, because they apply to any organisation building on AWS.

• A new AWS organisation starts with a low limit on the number of accounts. A design that separates logs from data needs several accounts from the first day. It is worth requesting the higher limit early, with the cost controls set out, rather than discovering the limit during the build.
• Where sign-in data is held is a design decision in its own right. The identity service sits in a region chosen when it is first set up, and it cannot be moved later. Personal data can stay in Mumbai while sign-in records sit elsewhere; that should be decided and recorded, not discovered.
• Every control needs its own test, including the guardrails themselves. A guardrail that blocks the wrong action can lock administrators out of the accounts they need. Testing each one in the sandbox first is slower, and it is the only safe order.

---

What this means for organisations preparing now

Most organisations will not build a reference system. They do not need to. The same thinking applies to any environment, and the time before May 2027 is enough to act on it if work starts now.

1. Work from the text of the law. Map each duty to an owner and to the systems that must make it true, using the Act and the Rules themselves rather than summaries.
2. Keep a personal data register that is tied to reality. Connect it to the infrastructure, so that a store holding personal data cannot exist without being recorded.
3. Separate the logs from the data, and lock them. Rule 6(1)(c) and 6(1)(e) are only as strong as the protection on the logs themselves.
4. Remove standing access. Replace permanent credentials with temporary, MFA-protected access, and keep administrator rights for emergencies.
5. Test the controls and keep the results. Rule 6(1)(g) asks for safeguards that work in practice. A test run that leaves tamper-proof evidence is the clearest way to show it.
6. Rehearse the seventy-two hours. Run a simulated breach and check that the information Rule 7(2) requires can actually be produced in time.

---

Following the work

DPDP in Practice is published as open source on GitHub at github.com/riturajb/dpdp-on-aws, with each release, its guide and its evidence model available to anyone. Updates are shared on LinkedIn as each release is published.

At Defenaar Consulting, this is the approach I bring to client work: starting from the law, building controls into the systems that must satisfy it, and leaving evidence that shows they work.

This article describes a reference implementation built with synthetic data. It is not legal advice. Organisations should take advice on how the DPDP Act and Rules apply to their own circumstances.