Running a DPDP Gap Assessment That Regulators Will Accept: Methodology for BFSI Practitioners

Not all gap assessments are equal. A consultant's generic ISO checklist renamed DPDP Gap Assessment will not survive a regulator inquiry. The question bank matters, the scoring methodology matters, and — above all — what you do with the findings matters.

The five-layer question bank

A credible DPDP gap assessment draws questions from five distinct regulatory and organisational layers. Each layer addresses a different dimension of compliance, and omitting any one of them produces a gap assessment that is incomplete by design.

Layer 1: DPDP Act §3–§16

The Act itself creates the baseline obligations: lawful processing (§4), notice (§5), consent (§6), data principal rights (§12–§14), data fiduciary duties (§8), breach notification (§8(6)), and significant data fiduciary obligations (§10). Your question bank must have at least one question per obligation category. If your assessment cannot trace every question to a specific Act section, the assessment is not anchored to the law — it is anchored to someone's interpretation of the law.

Layer 2: DPDP Rules 2025

The Rules add operational specificity that the Act deliberately left open. Consent manager registration requirements, breach notification format and timelines, SDF additional obligations including annual DPIAs and DPO appointment — these are not optional extensions but enforceable requirements. Questions at this layer test whether the organisation has operationalised the Rules, not just acknowledged the Act.

Layer 3: RBI DPSC controls (banking entities)

For RBI-regulated entities, the Digital Payment Security Controls framework adds six control domains: governance and accountability (§1), data inventory and classification (§2), consent and notice management (§3), assessment and risk management (§4), security safeguards (§5), and incident response (§6). These controls are specific to financial data processing and create obligations that go beyond the DPDP Act — particularly around data classification, cross-border transfer mechanisms, and third-party processor oversight.

Layer 4: SEBI CSCRF Chapter 5 (market entities)

SEBI-regulated entities — brokers, depositories, mutual fund houses, and market infrastructure institutions — face additional requirements under the Cyber Security and Cyber Resilience Framework. Chapter 5 addresses data protection controls specific to market operations: customer data segregation, trading data retention, depository participant data handling, and cross-market data sharing protocols. A gap assessment for a market entity that omits CSCRF questions is incomplete.

Layer 5: Organisation-specific questions

The final layer maps questions to the organisation's actual processing activities as documented in its ROPA. If your ROPA shows that the organisation processes biometric data for KYC, runs automated credit scoring, and shares data with three credit bureaus, then your question bank must include specific questions about each of those activities. Generic questions about "do you process sensitive data" are insufficient when the ROPA already identifies exactly what sensitive data you process and how.

Four-level maturity scoring

Binary pass/fail scoring is the single most common mistake in gap assessments. A control that exists in policy but has never been tested is not the same as a control that does not exist. A four-level maturity model captures the difference:

1. 0 — Absent: The control or process does not exist. There is no policy, no procedure, and no evidence of implementation. This is a material gap that requires immediate remediation.
2. 1 — Partial/undocumented: The control exists in practice but is not formally documented. Staff may follow the process informally, but there is no written policy, no defined ownership, and no evidence trail. This is common for consent management and data retention in organisations that have operated pre-regulation.
3. 2 — Documented: A formal policy or procedure exists, ownership is assigned, and staff are aware of it. However, there is no evidence of testing, no audit trail of execution, and no evidence that the control has been verified as effective.
4. 3 — Evidenced and tested: The control is documented, has been implemented, has evidence of execution (logs, screenshots, audit trails), and has been tested or reviewed within the last 12 months. This is the target state for regulatory readiness.

Scores are weighted across four dimensions: Documentation (30%), Risk Posture (25%), Control Maturity (25%), and Remediation (20%). This weighting reflects regulatory priorities — documentation is weighted highest because it is the first thing a regulator inspects, but it is not sufficient alone. A perfectly documented programme with untested controls scores well on documentation but poorly on maturity.

The CAPA discipline

Every finding from a gap assessment must produce a Corrective and Preventive Action record. A gap assessment without CAPA is not a compliance programme — it is an expensive document that creates liability without creating protection. The regulator will ask not just "what gaps did you find?" but "what did you do about them, and can you prove it?"

Each CAPA record must contain five elements: the finding it addresses (with reference to the specific gap question and regulatory provision), the assigned owner (by name and role, not by department), the deadline for completion, the evidence required to close the finding, and the ROPA activity reference that the finding relates to.

The ROPA activity reference is critical and frequently omitted. A finding that says "consent management is inadequate" is actionable only when it specifies which processing activities have inadequate consent. Linking findings to ROPA activities creates traceability: this finding relates to this processing activity, which processes this data, under this legal basis, with these safeguards. That chain is what a regulator is looking for.

CAPA records must be tracked to closure with evidence. "We implemented encryption" is not closure — a configuration screenshot, an audit log extract, or a penetration test report is closure. The gap assessment score should recompute as CAPA items are closed, giving the organisation a measurable improvement trajectory that can be reported to the board.

Common practitioner errors

These are the errors we see most frequently in gap assessments conducted by internal teams and external consultants across BFSI organisations:

• Binary pass/fail scoring: Reduces a nuanced compliance landscape to yes/no answers. A control that is partially implemented scores the same as one that is completely absent. This produces misleading aggregate scores and makes it impossible to prioritise remediation effectively.
• Failing to map findings to ROPA activities: Findings that float without connection to specific processing activities cannot be acted upon. "Consent management needs improvement" means nothing without specifying which processing activities have consent gaps.
• Closing findings without evidence: Marking a finding as remediated because someone says it has been fixed, without attaching evidence of the fix. This creates a false compliance posture that will collapse under audit scrutiny.
• Not linking gap scores to DPIA risk tables: Gap assessment findings about high-risk processing should feed directly into DPIA risk identification. If your gap assessment finds that automated credit scoring lacks adequate safeguards, that finding should appear in the DPIA risk table for the credit scoring activity — not exist in a separate document that nobody cross-references.