DPDP Rules 2025, Rule 6(1)(g): Organisational Measures, the Clause That Resists a Checklist

Part of a series on DPDPA Section 8(5) and DPDP Rules 2025, Rule 6. Read the pillar post first if you haven’t.

The Clause, Verbatim

“(g) appropriate technical and organisational measures to ensure effective observance of security safeguards.”

DPDP Rules 2025, Rule 6(1)(g)

Read this one twice. It’s a requirement to have measures that ensure your other measures are actually being followed. Every other clause in Rule 6(1) tells you what to build. This one tells you to build something that confirms the rest of it is actually working, on an ongoing basis, not just at the moment you first implemented it. It’s the clause that most explicitly resists being reduced to a checklist item, because a checklist can confirm a control exists. It can’t confirm the control is being observed.

What It Technically Requires

Documented security policies, covering each of the areas in Rule 6(1)(a) through (f): encryption and access standards, access control procedures, logging and monitoring practice, backup and continuity procedures, retention schedules, and processor management, written down, not held informally by whoever happens to know.

Assigned ownership and accountability. A named person or team responsible for each safeguard, and for the programme as a whole, so “ensure effective observance” has an actual owner rather than being everyone’s job and therefore no one’s.

Training and awareness. Employees and contractors who handle personal data understand the policies that apply to them. A backup procedure nobody on the team knows exists isn’t being observed, regardless of how well it’s documented.

Periodic internal audit or review. A recurring process, not a one-time setup exercise, that checks whether the technical safeguards in Rule 6(1)(a) through (f) are actually being followed in practice: are the access reviews from Rule 6(1)(b) actually happening on schedule, is encryption actually applied everywhere the policy says it should be, are backups actually being tested.

Change management. A process for updating security measures as systems, teams, and risks change, so the safeguards don’t quietly go stale while the infrastructure around them evolves.

Incident response and continuous improvement. A defined process connecting “we found a gap” (from monitoring, audit, or an actual incident) to “we fixed it and adjusted the underlying policy,” closing the loop rather than treating each incident as isolated.

Where This Gets Subjective

This clause is the most open-ended in the entire rule, and that’s arguably intentional. Every other sub-clause names a specific technical domain. This one names an outcome, “effective observance”, and leaves the means entirely open. That creates real, hard-to-resolve disagreement:

What counts as “effective”? A written policy plus an annual review satisfies a minimal reading. A dedicated security governance function, quarterly internal audits, continuous automated compliance monitoring, and a documented incident-to-policy feedback loop satisfies a much more rigorous reading. Both are “technical and organisational measures.” The clause gives no threshold for how much process is enough, which is precisely the kind of judgment call “reasonable” was always going to require, and no rule can fully specify in advance.

Whether tooling alone can satisfy an organisational requirement. A scanning or compliance-mapping tool can confirm that a control exists and is technically implemented. It’s a genuinely useful, often necessary part of demonstrating observance. But the clause asks for organisational measures too, ownership, training, review cadence, accountability, none of which a tool can manufacture on its own. Treating automated verification as a substitute for the organisational half of this clause, rather than as one input into it, is probably the single most common way this clause ends up under-satisfied in practice.

Proportionality to organisation size. What “effective observance” looks like at a five-person startup and a 5,000-person enterprise can’t reasonably be the same programme. The clause doesn’t scale itself, that calibration is left entirely to the Data Fiduciary, and it’s one of the areas where an honest, proportionate answer for your specific organisation will look different from a generic template answer.

What the Breakdown Really Means, for This Clause and the Whole Series

This is the clause where the argument that opened this series, that not everything under DPDPA can be captured as a checklist item, is most literally true. Rule 6(1)(a) through (f) can each be checked off in the narrow sense: encryption exists, access control exists, logs exist, backups exist, a contract exists, retention is one year. Rule 6(1)(g) explicitly asks whether all of that is actually being observed, in practice, over time, by an organisation that owns it.

That’s the throughline across all seven clauses in this series, and back to the pillar post’s original point: Rule 6 gives you the floor. Whether you’re standing on solid ground depends on what you build above it, and whether you keep maintaining it.

Vimalendukumar Dwivedi is Co-founder of Scrutora, a Code Compliance Platform.