If you are preparing for a DPDP audit, one of three things is happening.
You are being audited by a customer or partner as part of a security or procurement review, and they want DPDP-specific evidence. You are being audited by a Big 4 or specialist consultancy that you engaged proactively to establish readiness. Or you are being audited by the Data Protection Board of India (DPBI) because someone filed a complaint or your company was flagged for review.
The three scenarios have different stakes, different evidence requirements, and different failure modes. This guide walks through what each one actually looks at, what you should have prepared, and where most companies fall short.
The framing is engineering-first: what artifacts, evidence, and systems you need to produce, not just what documents to draft.
The three types of DPDP audit
Type 1: Customer or partner audit (procurement or contract-driven)
Who does this: Enterprise buyers running vendor due diligence. Payment processors verifying merchant compliance. Cloud partners onboarding new customers. Banks and NBFCs verifying LSPs (Loan Service Providers) and technology vendors.
What triggers it: A commercial contract. You are trying to sell or partner with an entity that has its own DPDP exposure and is transferring that risk to you through the contract.
Format: Usually a security questionnaire (100 to 300 questions), often DPDP-specific supplement to a broader SOC 2 or ISO 27001 questionnaire. Sometimes followed by a live review call with the customer's compliance or security team.
Stakes: Contract or renewal. Failure means losing the deal or delayed onboarding.
What they want to see:
- Executed privacy policy with DPDP-specific provisions
- Data flow documentation showing what customer data you process, where, and how
- Consent management approach
- DSR fulfilment process
- Sub-processor list with executed DPAs
- Breach notification commitment (typically 24 to 48 hours to notify the customer, ahead of your DPB obligation)
- Security controls: encryption, access management, audit logging
- Retention and deletion procedures
How you fail: Vague or evasive answers to specific questions. Missing sub-processor documentation. Cannot demonstrate consent audit trail. Cannot commit to breach notification SLAs the customer requires. Legal-only responses to technical questions.
How you win: A compliance program that produces genuine artifacts, not templates. Answers that reference specific systems, specific processes, specific evidence.
Type 2: Proactive third-party audit (Big 4, specialist firm, or internal audit)
Who does this: Your organization engages an external auditor for board comfort, investor diligence, insurance purposes, or genuine risk management.
What triggers it: Internal decision. Often prompted by an upcoming enterprise sale, an investment round, an insurance policy renewal, or a board-mandated risk review.
Format: Multi-week engagement, typically 4 to 12 weeks. Includes documentation review, control walkthroughs, evidence testing, interviews with technical and business staff, and a written report with findings and recommendations.
Stakes: Reputational and strategic. A weak report affects investor conversations, enterprise sales, board confidence.
What they want to see:
Every artifact from Type 1, plus:
- Complete Record of Processing Activities (RoPA)
- Data Protection Impact Assessment (DPIA) for high-risk processing
- Vendor risk management program with tiering, questionnaires, and periodic re-assessment
- Consent audit logs, sampled and verified against user actions
- DSR fulfilment logs showing timeline compliance
- Retention enforcement evidence (not just documented policies, actual system-level enforcement)
- Breach response tabletop exercise results
- Training records for staff handling personal data
- Board or executive oversight of the compliance program
How you fail: Documentation without operational evidence. RoPA that doesn't match what the code actually does. Retention policy that isn't enforced by system controls. Consent logs that don't reconcile with user actions. A privacy program that exists on paper but not in production systems.
How you win: Continuous operational evidence, timestamped and correlated across systems. The auditor tests a claim by pulling logs. The logs prove the claim.
Type 3: Data Protection Board of India audit or inquiry
Who does this: The DPBI, in response to a complaint, a notified breach, or a proactive review.
What triggers it:
- A Data Principal complaint alleging a violation
- A breach notification you filed under Section 8(6)
- Suo motu review of Significant Data Fiduciaries or high-risk sectors
- Referral from another regulator (RBI, SEBI, IRDAI)
Format: Formal proceedings under the DPDP Act. May involve document production requests, sworn statements, on-site inspection, expert witness engagement. Decisions are appealable to the Telecom Disputes Settlement and Appellate Tribunal.
Stakes: Penalties up to Rs. 250 crore per violation. Reputational damage. Potential injunctive orders affecting your operations.
What they want to see:
Everything Types 1 and 2 want, plus:
- Contemporaneous evidence (documents created at the time of the events, not reconstructed after the fact)
- Complete audit trail across the specific complaint or breach in question
- Detailed remediation actions taken after the incident
- Governance evidence: who was informed, when, what decisions were made, by whom
- Cross-referenced evidence across systems (a consent log entry, a database update, a processor notification, and a user-facing notification all reconciling to the same event)
How you fail: Missing contemporaneous evidence. Retroactively created documentation. Inconsistent timelines across systems. Cannot produce records for the specific user or event under review. Legal counsel answering technical questions.
How you win: A compliance program that has been operational, not retrofitted. Evidence pulled from live systems, timestamped, cross-referenced, provable.
The evidence categories: what you must have
Regardless of which type of audit you face, the evidence categories are the same. What differs is the depth and rigor.
Evidence Category 1: Governance
- Documented privacy program with defined roles
- Named Grievance Officer (published in privacy notice)
- Named Data Protection Officer if you are or may be designated an SDF
- Board or executive-level oversight (meeting minutes, quarterly reports)
- Training records for staff handling personal data
- Written policies covering data collection, processing, retention, deletion, breach response, third-party management
Evidence Category 2: Data inventory
- Record of Processing Activities (RoPA) that is current
- Data flow diagrams for major processing activities
- Data classification scheme (personal data, sensitive personal data, financial data, health data)
- Justification for lawful basis (consent or Section 7 legitimate use) for each processing activity
- Retention schedule per data category
A live data map is the foundation for this category. Without it, every other evidence pack is incomplete.
Evidence Category 3: Consent
- Copies of every version of every consent notice, versioned and timestamped
- Consent event logs sampling: verify a specific user, on a specific date, was shown a specific notice version, in a specific language, and took a specific action
- Withdrawal mechanism documentation and testing evidence
- Consent Manager integration evidence if applicable (post-November 2026)
Evidence Category 4: Rights fulfilment
- DSR log: every request received, request type, receipt date, completion date, actions taken, evidence of fulfilment
- Sample of completed DSRs with the actual outputs sent to Data Principals
- Grievance log with 90-day SLA adherence tracking
- Nominee handling process documentation
Evidence Category 5: Vendor and processor management
- Vendor inventory with categorization (processor vs sub-processor vs independent fiduciary)
- Executed DPA for every processor
- Vendor security assessment results
- Sub-processor consent or notification workflow
- Periodic re-assessment cadence and evidence
Evidence Category 6: Security controls
- Encryption at rest documentation for every personal data store
- Encryption in transit configuration
- Access control implementation (IAM roles, RBAC, MFA)
- Audit log retention (minimum one year per Rule 6)
- Vulnerability scanning and patching evidence
- Incident response tabletop exercise records
Evidence Category 7: Breach response
- Detection infrastructure documentation
- Breach classification workflow
- Notification templates (Data Protection Board and Data Principals)
- Historical breach records (if any) with full timeline evidence
- CERT-In and DPB notification integration
Evidence Category 8: Continuous compliance
- Change management process ensuring compliance review of new features
- Continuous PII discovery evidence
- Compliance drift detection alerts and remediation records
- Regulatory change tracking
For the engineering stack behind these categories, see DPDP compliance for engineering teams.
The five audit failures we see most often
Failure 1: Documentation without operational evidence.
The privacy policy claims 30-day retention for support tickets. The support system holds tickets for 3 years because nobody ever configured deletion. An auditor asks for evidence of enforcement. There is none. The gap between what your documents claim and what your systems do is the primary audit finding.
Failure 2: Point-in-time consent capture, no propagation trail.
You can show that user X consented to marketing on June 12. You cannot show that when user X withdrew marketing consent on August 3, that withdrawal propagated to Sendgrid, Klaviyo, and your CDP. The withdrawal event exists in your app. It does not exist in your processors' systems. This is a Section 6(4) violation.
Failure 3: DSR fulfilment with visible gaps.
You show 40 completed DSRs. The auditor samples one, User Y, and asks you to produce every location their data existed and confirm deletion from each. Your export lists your primary database. It does not list your analytics warehouse, which the auditor knows exists because your product homepage advertises analytics. The gap in scope is the finding.
Failure 4: Sub-processor blind spot.
You have DPAs with your direct vendors. The auditor asks about their sub-processors. You do not have that information. Sub-processors are where breaches actually happen (a small third-party analytics vendor of your CRM gets breached and your customer data leaks). Section 8(1) makes you liable for the entire chain. Sub-processor visibility is the gap.
Failure 5: Retroactive evidence generation.
The auditor asks for the breach response timeline for an incident from last quarter. Your team assembles a Slack-thread-based reconstruction. It is inconsistent, incomplete, and internally contradictory. Contemporaneous documentation would have preserved the actual timeline. Retroactive documentation looks like exactly what it is.
The 30-day audit prep sprint
If you have an audit coming up in 30 days and are starting from scratch, prioritize in this order.
Week 1: Inventory
- Run PII discovery across every data store
- Produce a current RoPA
- List every vendor and processor with their data flows
Week 2: Documentation
- Update privacy policy for current practices
- Draft or update DPAs for every processor
- Document consent mechanism (both current state and any planned changes)
- Document DSR fulfilment procedure
- Document breach response procedure
Week 3: Evidence collection
- Export consent logs and verify integrity
- Pull DSR history and format as evidence log
- Collect security control evidence (encryption configs, access logs, MFA enforcement)
- Assemble training records
Week 4: Gap remediation and dry run
- Fix any critical gaps identified in Weeks 1 to 3
- Run an internal walkthrough with the audit-facing team
- Prepare pre-populated responses for common questions
- Assemble evidence pack in a structured folder for auditor access
This will not produce a genuinely compliant program in 30 days. It will produce enough evidence to pass a Type 1 or Type 2 audit if your underlying practices are directionally correct. A Type 3 (DPBI) proceeding requires actual operational compliance, which cannot be manufactured in a sprint.
The 90-day audit prep program
If you have 90 days and want to build a program that survives Type 2 (proactive) or Type 3 (DPBI) scrutiny:
Month 1: Foundation
- Establish data map with automated discovery
- Fix the top 5 policy-to-practice gaps identified
- Implement consent propagation for the top 3 highest-volume processors
- Establish DSR self-service or ticketing workflow with SLA tracking
Month 2: Instrumentation
- Deploy continuous PII discovery with change alerts
- Implement retention enforcement (S3 lifecycle, DB scheduled deletes, DynamoDB TTL)
- Build breach detection alerting on anomalous data access
- Complete sub-processor inventory and DPA renegotiation
Month 3: Evidence and dry run
- Run a full internal audit against the DPDP checklist
- Conduct a breach response tabletop exercise
- Sample DSR fulfilment for evidence quality
- Fix findings from internal audit
- Prepare comprehensive evidence pack
At the end of 90 days you have a defensible program. Not perfect. Defensible.
The Significant Data Fiduciary (SDF) audit distinction
If you are designated an SDF under Section 10, additional obligations apply:
- Appoint a Data Protection Officer based in India
- Appoint an independent Data Auditor
- Perform periodic Data Protection Impact Assessments
- Perform periodic compliance audits
The "periodic compliance audit" is not the same as the Type 2 audit above. It is a formal audit by an independent auditor, submitted to the DPBI. The methodology, format, and evidence requirements are more rigorous.
If you might be designated an SDF (large e-commerce, social media, online gaming platforms are expected in the Third Schedule), start operating as if you already are. Retrofit is expensive.
The auditor perspective: what actually convinces them
Auditors are trained to look for the gap between what you claim and what your systems do. A convincing compliance program has three traits:
1. Live evidence, not documentation. When asked "how do you handle X," the answer references a system, and the system's logs verify the answer. Not "we have a policy that says X."
2. Consistent timelines across systems. For any single event (a consent, a DSR, a breach), the timelines line up across every affected system. Contradictions indicate reconstruction, not operation.
3. Ownership. For every compliance workflow, one person or team owns it. They can walk the auditor through it in detail without hesitation. "Compliance is handled by legal and IT" is not ownership.
If your program has these three traits, you pass Type 1 and Type 2 audits with room to spare. You are also prepared for the Type 3 case you hope never happens.
The self-diagnostic: can you produce this evidence in 24 hours?
Pretend the DPBI has issued a notice asking for evidence on a specific user. Answer these questions with confidence in under 24 hours:
- Which of our systems contain personal data for user_id 87421?
- What consents did they give, when, and in what language?
- Have they made any Data Principal requests? If so, when, what was the request type, when was it completed, and what evidence do we have?
- Which processors received their data, under what DPAs, and what was the sub-processor chain?
- What retention rules apply to their data, and where has it already been deleted per those rules?
- If we had a breach affecting the system containing their data, could we notify them within the required timeline?
If you can answer these in 24 hours, you are audit-ready. If you cannot, that is your starting point.
Where Privra fits
Privra runs continuous DPDP compliance assessments and generates the evidence trail your audit will actually require. Our AI agents produce:
- A live RoPA that updates as your infrastructure changes
- Continuous consent audit logs with propagation evidence
- DSR fulfilment tracking with cross-system reconciliation
- Vendor and sub-processor inventory with DPA status
- Compliance drift alerts with remediation guidance
The result is an evidence-first compliance posture: when the audit comes, the artifacts are already assembled.