
DPDPA Section 36: Power to Call for Information and Its Practical Impact
When regulators knock, you must answer. DPDPA Section 36 enforces compliance through mandatory information requests. Ensure your business is ready to respond.
Written by
Priyanka Choudhury
Date
Read time
6 min

You can write the best privacy policy in the world, but it means nothing if you cannot prove you follow it when the regulator knocks. DPDPA Section 36 is that knock.
It authorizes the government and the regulator to access the information they need to oversee compliance. It is a straightforward enforcement lever: if the authorities ask for information, you must provide it.
What Section 36 Authorizes
The provision states that the Central Government may, for the purposes of the Act, require the Board and any Data Fiduciary or intermediary to furnish information it calls for. In parallel, the interpretation aligned to Section 36 explains that the Data Protection Board can request and obtain information necessary to perform its duties. Both avenues exist to ensure oversight is not blocked by a lack of access.
Rule 22 under the applicable DPDP Rules 2025 is the operational hook connected to this power for Data Fiduciaries and intermediaries. It clarifies that the regulator can call for information from these entities.
The takeaway is simple. If you are subject to the Act or you hold relevant information, you must be ready to produce it. A polite request from the regulator is not an invitation to negotiate. It is a demand for evidence.
Who Can Be Required to Furnish Information
Section 36 explicitly covers:
- The Data Protection Board, when the Central Government calls for information.
- Any Data Fiduciary or intermediary.
But the net is cast wider than just the primary targets. The accompanying interpretation extends the scope of information requests for the Board’s work to any party that holds relevant details about personal data handling. This includes:
- Data Fiduciaries.
- Data Processors.
- Third parties with relevant information.
The intent is to remove blind spots during investigations, compliance checks, and sector reviews. If you influence, enable, or execute personal data processing, expect that you may be asked to explain or document it. You cannot hide behind a vendor contract.
Why the Information is Sought
Information requests under Section 36 serve clear, uncompromising purposes:
- Compliance checks. To verify security controls, consent mechanisms, retention practices, and the effectiveness of rights handling such as erasure.
- Enforcement and investigations. To gather evidence after a suspected breach, incident, or complaint, and to determine whether obligations were met.
- Policy and oversight. To understand industry practices, detect patterns, and support guidance or rulemaking where systemic risks are identified.
The regulator is not fishing. It is using targeted requests to confirm facts, close gaps, and enforce the law.
Legal Obligation and Due Process
Once a notice or request is issued, the recipient is legally required to respond fully and in a timely manner. Refusal, undue delay, or misleading responses invite enforcement action, including penalties. The legal weight behind this power is exactly what makes it effective.
At the same time, the Board must act lawfully and reasonably. Procedural safeguards, including opportunities for representation, help ensure the process is fair. Expect structured requests tied to clear regulatory objectives, and be prepared to respond with documented, verifiable information. Excuses do not scale.
What You Should Expect to Produce

The interpretation of Section 36 highlights the types of materials commonly sought to assess compliance and investigate issues. Be prepared to produce:
- Technical documents and security protocols, including encryption standards and access controls.
- Policies and procedures covering consent, retention, erasure, and incident response.
- Audit reports, assessment results, and remediation records.
- Records of how user requests are handled, such as deletion or correction logs.
- System access logs and other operational evidence that show how controls work in practice.
- Vendor and processor contracts that define roles, safeguards, and breach obligations.
The exact scope will vary by case, but the theme is consistent. The regulator wants evidence that your program is designed well and works in practice. Because a policy that does not reflect reality is just a well-written lie.
Illustrative Scenarios
How does this look in the real world?
- Compliance verification for a social platform. The Board may request retention policies, encryption standards, and evidence of how deletion requests are processed. The goal is to confirm that user rights and security duties are being met.
- Investigation after a suspected bank breach. The Board may seek security audit reports, incident response plans, access logs, and vendor contracts. The focus is on whether reasonable safeguards were actually in place and followed, not just drafted.
- Sector review of children’s data in EdTech. The Board may request age verification methods, parental consent practices, and advertising policies across multiple providers. Common shortcomings can lead to sector guidance.
These scenarios show both targeted enforcement and broader oversight. The same underlying duty applies: produce accurate, complete, and timely information.
Practical Implications for Teams

Translate Section 36 into operational readiness, because scrambling during a regulatory inquiry is a losing strategy.
- Map your evidence. Know where your key documents live. Policies, standards, risk assessments, audit reports, and logs must be current and retrievable.
- Align your records to obligations. Maintain clear records of consent collection, erasure handling, retention enforcement, and breach response. Evidence beats assertions.
- Tighten vendor files. Keep contracts, due diligence results, and incident obligations for processors and other third parties in order. Be able to show how you govern downstream processing.
- Prepare for investigative asks. Ensure your teams can export access logs, incident timelines, and change histories without manual scrambling. Practice a mock data request to find gaps.
- Set ownership and timelines. Assign clear owners for legal, security, engineering, and operations inputs. Have a playbook for responding to notices with defined internal SLAs.
- Document rationale. If you make risk-based choices on retention, security, or children’s data handling, record the basis. Measured decisions supported by documentation stand up better under scrutiny.
Non-cooperation is a high-cost strategy. A disciplined response reduces exposure and shortens the window of uncertainty.
Boundaries and Interpretation
- Central Government power. Section 36 allows the government to require information from the Board and any Data Fiduciary or intermediary for Act purposes.
- Board power. The interpretation explains that the Board can call for information needed to perform its statutory role, including from Data Fiduciaries, Data Processors, and third parties. This aligns with the Data Protection Board of India powers for oversight, investigation, and enforcement.
- Rules linkage. Rule 22 under the 2025 Rules ties the call-for-information mechanism to Data Fiduciaries and intermediaries. Expect formal notices anchored in this rule.
Treat these powers as complementary. They ensure no critical information stays out of reach when compliance is at stake.
Bottom Line
Section 36 is a practical enforcement tool. It enables the Central Government and the Board to obtain the information needed to verify compliance, investigate failures, and shape guidance. For organizations, the message is clear. Keep your program evidence in order, your vendor governance tight, and your response playbook ready.
Real execution often breaks on version control, scattered logs, and unclear ownership. That is the difference between passing an audit on paper and surviving a regulatory inquiry in reality.
At Regodit, we built our platform because we know that managing requests, evidence, and timelines on spreadsheets is a recipe for failure. Regodit helps teams organize obligations, evidence, and responses in a way that stands up under regulatory scrutiny. If you want a structured way to manage your posture and discuss a practical approach to Section 36 readiness, let’s talk.
Disclaimer: The views and explanations shared in this blog are based on our team's understanding of the relevant compliance frameworks. While every effort has been made to ensure accuracy, readers are encouraged to refer to the original legal provisions and official notifications for authoritative guidance. Please reach out to us at connect@solsphere.ai.
Keep reading
All blogs →DPDPA Rule 23: Government Requests for Information from Data Fiduciaries and Intermediaries
Handling a notice under DPDP Act Rule 23 requires strict confidentiality. Discover how to respond to government data requests and ensure full compliance.
DPDPA Rule 22: Appeals to the Appellate Tribunal
Lost at the Data Protection Board? DPDPA Rule 22 governs the digital-first appeals process. Read our complete guide to filing an appeal with the Tribunal.
DPDPA Rule 21: The Machinery Behind the Data Protection Board of India
Ensure your business meets DPDP Act compliance requirements. Discover key obligations for data fiduciaries, penalty risks, and steps to protect user privacy.
