The Ultimate DPDP Act Compliance Framework: Audit and Testing Checklist

The Technical Reality of DPDP Act Compliance

Most Indian organisations are treating 13 May 2027 as a distant date. It is roughly eight months away, and the work sitting behind it is engineering work, not legal drafting.

That is the part that the market keeps getting wrong. When the Digital Personal Data Protection Act, 2023 was passed, the obligation to implement “reasonable security safeguards” under Section 8(5) read like a principle. Lawyers could interpret it. Nobody had to rebuild anything.

The DPDP Rules, notified on 13 November 2025, closed that gap. Specifically, Rule 6 turned the principle into a named list of technical controls: encryption, access control, logging and monitoring, backups with tested restoration, and retention of logs for at least one year. Rule 7 set a 72-hour clock for reporting breaches to the Data Protection Board. Furthermore, Rule 13 requires Significant Data Fiduciaries to complete an independent audit every twelve months. Finally, Rule 14 caps grievance response at 90 days.

None of that is satisfied by a policy document. Every item must be in production, and someone must be able to prove it.

Why the Penalties Demand Immediate Engineering Action

The penalty structure explains why such an issue gets board attention. The Schedule to the Act sets a ceiling of ₹250 crore for failure to implement reasonable security safeguards, and ₹200 crore for breach notification failures. Those are maxima rather than tariffs, and Section 33 factors apply before an amount is fixed, but the ceiling is what gets quoted in a board paper.

This guide is for those who build the evidence, not those who interpret the law. It covers what Rule 6 actually specifies, what the audit obligations are and who they bind, what to test and how, how to handle processors, what the breach clock really demands when CERT-In’s six-hour obligation is running alongside it, and a DPDP Act compliance framework checklist you can work through with your engineering team.

Where the Act and Rules are silent on something the market claims they require, this guide says so plainly. There is more of that than you would expect.

Who Must Comply? Data Fiduciaries and the Scope of DPDP

Before scoping any technical work, establish which side of each definition you sit on, because the obligations differ sharply.

For a comprehensive overview of how these legal frameworks apply across industries, you can review our guide on DPDP compliance for Indian businesses.

The three roles

• Data Fiduciary. Any person who alone or with others determines the purpose and means of processing personal data. If you decide why you collect data and how you use it, you are a fiduciary. The accountability sits here, and it does not transfer to your vendors.
• Data Processor. Any person who processes personal data on behalf of a fiduciary. Processors act on documented instructions and must implement equivalent security safeguards, but the fiduciary remains answerable to the Board.
• Data Principal. The individual the data relates to. For a child, the data principal includes the parent or lawful guardian. For a person with a disability, this includes the lawful guardian.

Most Indian companies are fiduciaries for their customer and employee data and processors for anything they handle on a client’s behalf. Both sets of obligations then apply simultaneously to different datasets, which is a distinction worth writing down before scoping an audit.

Territorial scope

The Act applies to the processing of digital personal data within India. It also applies outside India, where the processing relates to offering goods or services to data principals inside India.

That second limb catches foreign SaaS providers with Indian users, and it catches Indian subsidiaries of multinationals who assumed group-level GDPR compliance covered them. It does not.

What counts as personal data

Any data about an identifiable individual. Names, email addresses, phone numbers, device identifiers, location data, and anything that identifies a person in combination with other data you hold.

Two clarifications that come up repeatedly in scoping conversations.

The Act has no separate sensitive personal data category. Unlike the old SPDI Rules and unlike GDPR, DPDP does not create a special tier for health, financial or biometric data. In practice, sensitivity still matters, because Rule 6 requires safeguards proportionate to risk and the Board will weigh the nature of the data when assessing whether they were reasonable. However, there is no statutory sensitive-data classification to anchor a control design.

Only digital data is covered. Personal data in purely physical form falls outside the Act, but data that is digitised later comes within scope.

Core data fiduciary compliance obligations

The compliance timeline

This is the section most outlines omit and the one every compliance officer asks about first.

Eighteen months sounded generous in November 2025. What it means practically is that the data mapping, consent re-architecture, control implementation, vendor re-contracting and evidence generation all have to be completed within that window, and most organisations have not started the technical half.

Commentary from Indian counsel consistently makes the same point: the runway is generous, and they expect enforcement afterwards to be strict. Use the time on the engineering, because the legal documentation can be produced faster than the controls can.

The Tech-Privacy Gap: Where Legal Compliance Meets Security Engineering

There is a recurring failure pattern in Indian DPDP programmes, and it is worth naming before the technical sections.

The legal team completes its work. Privacy notices are rewritten. Consent language is approved. A records-of-processing register exists in a spreadsheet. The board is briefed. On paper, the organisation is compliant.

Then somebody asks an engineer whether personal data is encrypted at rest in the analytics warehouse, and nobody knows.

Where the gap opens

Legal work produces documents. Rule 6 requires running controls. A privacy policy stating that data is encrypted is not evidence of encryption. The configuration export is.

Data maps go stale immediately. A register compiled through interviews reflects what teams believed in the month it was written. Personal data moves constantly: into a new analytics pipeline, into a support ticketing system, and into a vendor’s environment through an integration nobody documented.

Consent architecture is a product problem, not a legal one. Engineering is required to capture consent, store it with an audit trail, propagate withdrawal to every downstream system, including processors, and prove all of it later. Withdrawal propagation is the part almost nobody has built.

Erasure is harder than it reads. Section 8(7) and Rule 8 require that erasure occurs when the purpose is served. Doing that across primary databases, replicas, backups, warehouses, logs, caches and vendor systems is an architectural problem.

The four questions that expose it

Ask these in your next DPDP steering meeting. The answers will tell you where the programme actually stands.

1. Can you produce a current list of every system holding personal data, with an owner against each? This document is not the register from the kickoff workshop. 
2. If a data principal requests erasure today, can you delete their data from backups and from every processor within 90 days?
3. If your logs retain personal data for the year Rule 6 requires, what is your exposure if those logs are breached?
4. Can you provide evidence, with a configuration export rather than a policy, that access controls restrict personal data to authorised personnel?

Most organisations answer ‘no’, ‘do not know’, or ‘not yet’. That is the gap, and closing it is engineering work on an engineering timeline.

For teams navigating this complexity, partnering with experienced expert DPDP consultants helps bridge the divide between legal policy and technical execution.

Why this matters for how you scope an audit

A legal gap assessment tells you which documents are missing. A technical audit tells you which controls do not exist or do not work. They are different exercises, and both are needed.

The rest of this guide covers the second one, which is the harder half and has the longer lead time.

See How Experts Spot and Fix Security Flaws?

Penetration testing is a mandatory step for ISO 27001. Check out a real sample to see how security risks are found, written up, and fixed.

Download Sample VAPT Report→

Deconstructing “Reasonable Security Safeguards” Under Section 8(5)

Section 8(5) obliges every Data Fiduciary to implement reasonable security safeguards to prevent personal data breaches, including in respect of data held by processors. Rule 6 converts that duty into a specified baseline: encryption or equivalent obfuscation, access controls, logging and monitoring, backups with continued-processing capability, one-year log retention, and contractual flow-down to processors.

What counts as reasonable security safeguards? DPDP-wide is no longer a matter of interpretation, and this provision is the heart of the framework, so it gets the most detail.

What Rule 6 actually specifies

Rule 6 breaks the general duty into concrete measures. The baseline, as specified:

Read that table as a control inventory rather than as legal text, because that is how an auditor will read it.

The word “reasonable” still does work

Rule 6 sets a baseline, not a ceiling. The standard remains proportionate to your risk profile, which means a payment platform that processes crores of transactions and a twelve-person B2B SaaS company are not held to the same implementation, though both must implement each category.

When the Board assesses reasonableness, four things will plausibly inform it: the nature and volume of data processed, alignment with recognised frameworks such as ISO/IEC 27001 and the NIST Cybersecurity Framework, your sectoral obligations under CERT-In, RBI, SEBI or IRDAI, and the quality of your governance, testing and incident response.

A caution worth stating clearly. Nobody can currently tell you with authority how the Board will interpret reasonableness, because enforcement practice does not yet exist. Any vendor presenting a definitive DPDP security standard is extrapolating from the text, as is this guide. What the text does support is that the seven categories above are the floor.

The one-year log retention trap

This deserves its own treatment, because it is the clearest example of two DPDP obligations pulling against each other, and almost nobody writes about it.

Rule 6 requires you to retain logs for at least one year. Your application logs whatever your developers told it to log. If those logs contain raw Aadhaar numbers, PAN, phone numbers or account details, then complying with the retention obligation creates a 365-day store of personal data that is itself subject to Section 8(5), Rule 8 erasure obligations, and Rule 7 breach notification if exposed.

Here is the pattern as it usually appears in an Indian fintech or KYC platform:

Nothing in that code is wrong from an availability or debugging standpoint. It is a perfectly ordinary log line, and it will pass every scanner you point at it. The problem only becomes visible when you read the retention configuration next to the log schema.

The fix keeps the retention obligation intact while removing the liability:

Why the fix works –

The log still supports detection, investigation and remediation, which is what Rule 6 requires of it. A salted one-way reference lets an investigator correlate events involving the same individual without the log holding the identifier. Redaction is enforced at the logging transport rather than at each call site, so a developer adding a new log line next quarter inherits the protection automatically.

Limitations worth stating –

Hashing is not anonymisation when the input space is small and enumerable, as is arguably the case with a twelve-digit Aadhaar number, so the salt must be kept separate from the logs and rotated. Transport-level redaction depends on field naming discipline, so pair it with a periodic log sample review. And this addresses application logs only; database audit logs, WAF logs and vendor platform logs each need the same treatment.

That tension between two rules in the same instrument is the kind of thing a legal gap assessment will not surface and a technical audit will.

What Are the Digital Personal Data Protection Audit Requirements?

The DPDP framework imposes a formal audit obligation only on Significant Data Fiduciaries. Under Rule 13, SDFs must undertake a Data Protection Impact Assessment and an independent audit once every twelve months. Other Data Fiduciaries face no statutory audit mandate, but still carry the Section 8(5) duty and the practical need to evidence it.

Understanding which of those two positions you occupy determines your budget and your calendar, so this section separates them carefully.

If you are a Significant Data Fiduciary

The Central Government may designate any fiduciary or class of fiduciaries as significant, having regard to the volume and sensitivity of data processed, the risk to data principals’ rights, the potential impact on India’s sovereignty and integrity, the risk to electoral democracy, the security of the state, and public order.

Once designated, Section 10 and Rule 13 impose additional obligations:

Two operational implications follow. The DPO must be in India, which is a hiring or restructuring decision rather than a documentation exercise. And the audit is annual and independent, which means it goes on the calendar permanently rather than being commissioned once before a deadline.

If you are not a Significant Data Fiduciary

No statutory audit is required of you. That is worth saying plainly, as several vendors are selling mandatory DPDP audits to organisations that have no such obligation.

What you do have is Section 8(5), and the practical problem is that safeguards you cannot evidence are difficult to defend. Three situations will require you to produce evidence regardless of designation:

After a breach. Rule 7 requires a detailed report to the Board within 72 hours. That report will be read alongside whatever you can show about the controls that were supposed to prevent it.

During enforcement. If the Board investigates, your defence is the evidence pack, and Section 33 requires the Board to consider the nature and gravity of the breach and any action taken to mitigate it.

In commercial due diligence. Enterprise customers and insurers are already asking about DPDP readiness in security questionnaires, and that trend will sharpen as May 2027 approaches.

So the sensible position for a non-SDF is to conduct a voluntary annual technical assessment focused on the Rule 6 controls, which costs considerably less than a full compliance audit and produces the evidence that actually matters.

What a DPDP audit should cover

Whether statutory or voluntary, a useful audit covers four layers rather than one.

Layer 1, governance. Policies, roles, DPO or contact person, training records, board reporting, and risk acceptance decisions with approver and date.

Layer 2, data. Data inventory and classification, processing register, lawful basis per processing activity, consent records and withdrawal propagation, retention schedules against the Third Schedule defaults, and cross-border transfer positions.

Layer 3, technical controls. Every Rule 6 category is tested rather than attested. The topic is covered in sections 6 and 7.

Layer 4, third parties. Processor inventory, contracts with the security schedule, evidence of processor safeguards, and offboarding records.

Most audits do layers one and two well and layers three and four poorly, because the first two are documentary and the second two require testing.

The distinction to hold onto

A compliance audit asks whether your process exists and operates. A security assessment asks whether your controls hold when someone attacks them. The Rules require the first of SDFs, while a compliance security audit under Section 8(5) effectively requires the second of everyone, without naming it.

Target Areas: DPDP-Specific Penetration Testing Requirements

Neither the DPDP Act nor the DPDP Rules require penetration testing. No section, no rule, no schedule names it. What Rule 6 requires is a set of security safeguards, and testing is the most direct way to establish whether those safeguards actually work. Anyone telling you DPDP mandates an annual pentest is describing a market convention, not the law.

That correction matters commercially, so this section first states the position and then covers what to test.

What the law actually says

Search the Act and the Rules for “penetration testing”, and you will not find it. You will find “reasonable security safeguards” and, in Rule 6, a list of measures. The word “reasonable” imports a standard of care that is assessed against your risk profile and against what comparable organisations do.

That is where testing enters. Testing is not a mandate, but it serves as evidence. If the Board examines whether your access controls restricted personal data to authorised personnel, a test report demonstrating through advanced penetration services that a low-privileged account could not reach another customer’s records is stronger evidence than a policy stating that it could not.

Compare this approach with the neighbouring Indian regime. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines and the sectoral frameworks under RBI and SEBI do specify testing cadence and auditor empanelment. DPDP does not. If you are regulated under those regimes as well, your testing obligation comes from there, and the DPDP evidence is a by-product.

So the honest framing of DPDP penetration testing requirements is as follows: there are none by name, and testing remains the most defensible way to evidence the requirements that do exist.

What to test, mapped to Rule 6

Each Rule 6 category translates into specific test cases. This mapping is what makes a test report usable as DPDP evidence rather than as a generic security document.

The five target areas that matter most

If the budget forces prioritisation, these five produce the highest-value DPDP findings.

1. Object-level authorisation on every endpoint returning personal data. This is the single most damaging category. An endpoint that authenticates the caller but never verifies the record is theirs converts one exposed record into the whole database. Automated scanning cannot find it, because the request is well-formed, correctly authenticated, and returns a valid response. Rigorous API security testing is essential to uncover these logic flaws.
2. Masking at the serialisation layer. Test the API directly rather than through the interface. The gap between what the UI shows and what the endpoint returns is where Aadhaar and PAN exposure live.
3. Log content and retention configuration. Sample actual log records for personal data. Check the retention setting on each source against the policy. Verify the storage region.
4. Erasure completeness. Submit a test erasure request and trace it. Primary database, read replicas, analytics warehouse, caches, search indexes, backups, and every processor. This process is rarely tested and almost never complete.
5. Consent withdrawal propagation. Withdraw consent on a test account and verify that downstream processing actually stops, including at the processors. Most implementations record the withdrawal and continue processing.

Items four and five are DPDP-specific. They do not appear in a standard penetration test scope, and they are precisely the controls the Act creates. Specify them explicitly, or your provider will not test them.

Cadence

No frequency is prescribed. A defensible pattern for an Indian organisation is an annual technical assessment scoped to the Rule 6 mapping above, plus testing triggered by changes to authentication, authorisation, the data model, the processor estate, or the externally exposed surface. SDFs align their work with the Rule 13 annual audit cycle.

The Ultimate DPDP Security Audit and Validation Checklist

This is the working DPDP compliance checklist India teams can hand straight to an engineering lead. Work through it with compliance in the room. Each item is either evidenced or it is not, and there is no partial credit when the Board asks.

 1st stage: Govern

• DPDP accountability assigned at board or executive level, minuted
• DPO appointed and India-based, if designated an SDF; contact person published otherwise
• Grievance officer designated, with contact details prominently published on website and app
• Grievance workflow capable of responding within the 90-day cap under Rule 14, with acknowledgement, tracking and internal escalation
• DPDP policy is currently dated and version-controlled.
• Risk acceptance decisions are documented with the named approver, date and expiry.
• Training delivered to engineering, support and marketing, with completion recorded
• Compliance calendar tracking DPDP alongside CERT-In and sectoral obligations

2nd stage: Map

• Personal data inventory complete, with owner and classification per dataset
• Processing register listing purpose, lawful basis and retention per activity
• Data flow diagrams covering collection, processing, storage, sharing and deletion
• Every system holding personal data identified, including analytics, support tooling, CRM and backups
• Cross-border transfer positions documented per dataset
• Third Schedule applicability assessed, if you are an e-commerce, online gaming or social media entity above the specified user thresholds
• Children’s data processing was identified, with Rule 10 obligations mapped.
• Legacy data assessed, since pre-existing data is not exempt

3rd stage: Secure, the Rule 6 baseline

• TLS 1.2 minimum and 1.3 preferred, no downgrade path, verified by configuration, not policy
• Encryption at rest across databases, object storage, backups and snapshots
• Key management documented, with rotation records and separation from the data
• Masking or tokenisation applied at the serialisation layer, verified against the API rather than the interface
• Access controls restricting personal data to authorised personnel, evidenced by IdP configuration export
• MFA enforced on all administrative and remote access, break-glass accounts documented
• Access recertification is running on a defined cadence with reviewer sign-offs.
• Logging covers actor, action, object and outcome for personal data access.
• Monitoring and alerting configured for unauthorised access patterns, including enumeration
• Log retention verified at one year minimum per source, against actual configuration
• Log content audited for personal data, with redaction enforced at the transport
• Backups configured, encrypted, and restore-tested with results recorded
• Continued processing capability documented with RTO and RPO per critical service

4th stage: Prove

• Annual DPIA completed, if an SDF
• Annual independent audit completed, if an SDF
• Technical assessment scoped to the Rule 6 mapping in section 6
• Object-level authorisation tested across roles and tenants, using at least two accounts per role
• Erasure completeness tested end to end, including processors and backups
• Consent withdrawal propagation tested to downstream systems
• Findings mapped to Rule 6 categories in the report, not just to OWASP
• Retesting completed and closure evidenced with dates
• Evidence pack indexed by Rule and control, ready to hand over

5th stage: Sustain

• Breach response runbook covering both the Rule 7 72-hour clock and CERT-In’s six-hour obligation
• Breach notification templates pre-drafted for the Board and for data principals
• The rights request workflow was tested end to end, within the 90-day cap
• Erasure automation implemented or a documented manual process with an owner
• Processor registers current, with contracts and evidence per vendor
• Vendor offboarding, including credential and API key revocation
• Data inventory reconciled quarterly
• Trigger list for out-of-cycle testing, owned and reviewed at release planning
• The next assessment is diarised before the current one closes

Pre-audit documentation pack

Index these before an auditor arrives. An indexed pack routinely saves days.

Governance: policy set, board minutes recording DPDP accountability, DPO or contact appointment, training records, risk acceptance register, previous assessment reports with closure evidence.

Data: inventory with owners, processing register, data flow diagrams, retention schedules, consent records sample, and cross-border transfer documentation.

Technical: TLS and encryption configuration exports, key management records, IdP and access control configuration, access recertification sign-offs, log source coverage matrix with retention settings, log sample showing redaction, backup configuration and restore test results.

Third parties: processor registers with tiers, executes contracts with security schedules, processor assessment evidence, and offboarding records.

Incident: breach response runbook, escalation matrix with out-of-hours cover, notification templates, records of any prior notifications to the Board or CERT-In, tabletop exercise records.

Prepare for Your Next Cybersecurity Audit with Qualysec

Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.

Talk to an Expert→

Managing the Vendor Risk: Data Processors and Third-Party Code

Section 8(2) makes the Data Fiduciary responsible for compliance in respect of processing undertaken on its behalf by a processor. Rule 6 requires contractual provisions obliging processors to implement reasonable security safeguards. The accountability does not transfer with the data.

That single principle drives everything in this section, and it is the one most commonly misunderstood at the contract stage.

What the contract must do

A DPDP-ready processor contract goes beyond a standard confidentiality clause:

• Processing only on documented instructions from the fiduciary
• Equivalent security safeguards, mapped to the Rule 6 categories rather than described generically
• Breach notification to the fiduciary fast enough for you to meet your own 72-hour obligation to the Board, which in practice means hours rather than days
• Assistance with data principal rights requests, within a timeframe that lets you meet the 90-day cap
• Deletion or return of personal data on termination, with certification
• Sub-processor restrictions, with notification and approval
• Audit rights, or at minimum a right to receive assessment evidence
• Log retention aligned to the one-year requirement, where the processor holds the logs
• Cooperation duties in any board investigation

The breach clause deserves particular attention. If your processor’s contract allows them 72 hours to notify you, your own 72-hour clock has expired before you learn anything.

Assessing processors in practice

Tier your vendors by the personal data they touch and the criticality of the service, then apply proportionate diligence.

Third-party code is a processor problem wearing a different hat

This is the gap most vendor risk programmes miss. Your vendor register tracks contracts. It does not track the analytics script, the chat widget, the tag manager container or the npm package that reached production through a pull request.

Each of those may transmit personal data to a third party. Under DPDP, that is processing on your behalf, and you are accountable for it.

What to check:

• Client-side scripts. Inventory every third-party script on pages handling personal data. Analytics, session recording, chat widgets, advertising pixels and tag managers frequently capture form field contents. Session recording tools are particularly exposed because they capture what a user types before submission.
• Tag manager containers. Often administered by marketing without security review, and capable of injecting arbitrary script.
• SDKs in mobile applications. Analytics and crash reporting SDKs commonly transmit device identifiers and sometimes more.
• Dependency provenance. Maintain an SBOM and monitor for compromised packages.
• Data flowing to advertising platforms. Check what your pixels actually transmit, not what the integration guide says they transmit.

A practical starting point: open your production site in a browser with the network tab recording, submit a form containing personal data, and list every external domain that receives a request. The list is usually longer than the vendor register.

Offboarding

The control most often absent entirely. Vendors are onboarded carefully and offboarded by cancelling the invoice, and their API keys continue to work.

Offboarding must include credential and API key revocation, confirmation of data deletion or return, removal from the processor register, and revocation of any OAuth grants. Diarise a verification check thirty days after termination.

The 72-Hour Drill: Breach Notification Obligations Under DPDP

Rule 7 creates a two-tier duty. On becoming aware of a personal data breach, the Data Fiduciary must intimate affected data principals without delay, and provide a detailed report to the Data Protection Board within 72 hours. Most Indian organisations also carry CERT-In’s six-hour obligation, and the two clocks run simultaneously to different bodies.

This section covers both clocks, because handling one and missing the other is a common and expensive outcome.

What Rule 7 requires

To affected data principals, without delay. The intimation must describe the nature, extent and timing of the breach, the likely consequences, the mitigation measures being taken, the safety measures the individual can take, and the contact details for further information. It goes through registered communication channels.

To the Board, within 72 hours of becoming aware. A detailed report covering the circumstances, the persons involved where known, the remedial measures taken, the notifications issued to data principals, and the findings of any inquiry.

Note the trigger. It is awareness of the breach, not confirmation of its scope. Waiting until you have a complete picture will consume the window.

The dual-clock problem

Here is the operational reality most breach runbooks in India do not account for.

The two overlap without matching. A ransomware event affecting a system holding customer data triggers both. A targeted scan of your network triggers CERT-In only. An accidental email disclosing one customer’s details to another triggers DPDP only.

Your runbook therefore needs a decision step at the top: does this incident trigger CERT-In, DPDP, both, or neither. That determination must be made in minutes, not hours, because the shorter clock is already running.

Building a runbook that survives a Sunday

The failure is rarely technical. Detection works. The reporting decision does not work because nobody owns it outside business hours.

Name owners with 24-hour contact. Each obligation should have a primary and a backup. Put them in the on-call rota, not in a policy document.

Pre-draft the templates. The CERT-In format, the Board report, and the data principal intimation. Drafting under pressure wastes the hour you need for containment.

Write the decision rule. Agree in advance with legal: what constitutes awareness, what constitutes a personal data breach, and who makes the call.

Log the clock. Record the moment of awareness with a timestamp and who noticed. If you later have to defend the timeline, that record is your evidence.

Test it out of hours. Run the tabletop at 11 pm on a weekend. A test conducted at 3 pm on a Tuesday has not tested the thing that fails.

Pre-agree processor notification. Your contract should require processors to notify you fast enough that their delay does not consume your window.

Why this connects to Section 8(5)

A breach report to the Board is read alongside your security posture. Section 33 requires the Board to consider the nature and gravity of the breach and the action taken to mitigate it when determining penalty.

An organisation that reports promptly, with a clear timeline, evidence of the controls that were in place, and documented remediation is in a materially different position from one that reports late and cannot explain what happened. The evidence pack from section 7 is what makes the first version possible.

The Cost of Inaction: Penalties, Gaps, and Hidden Risks

The Schedule to the DPDP Act sets penalty ceilings up to ₹250 crore for failure to implement reasonable security safeguards and up to ₹200 crore for breach notification failures. These are maxima rather than fixed amounts, and Section 33 requires the Board to weigh specific factors before determining any penalty.

Understanding how the numbers work and what else non-compliance costs are is the section that usually secures the budget.

The penalty structure

Two points that the headline figures obscure.

These are ceilings. Section 33 requires the Board to consider the nature, gravity and duration of the breach, the type and nature of personal data affected, whether the breach is repetitive, whether the person realised a gain or avoided a loss, what action was taken to mitigate it and how timely and effective that was, proportionality, and the likely impact of the penalty.

That list is where a testing and evidence programme pays off. Every factor except the first two is about what you did, and documented remediation, prompt notification and demonstrable controls all count.

The security safeguard ceiling is the highest. That is a deliberate signal. Under DPDP, failing to secure data is treated as more serious than most procedural failures.

The costs that never reach a board paper

Operational disruption. Breach response consumes engineering capacity for weeks. Roadmaps slip. In regulated sectors, supervisory attention follows.

Commercial drag. Enterprise security questionnaires already ask about DPDP readiness, and that will intensify through 2027. An unanswerable questionnaire turns a three-week deal into a three-month one, or loses it.

Remediation under pressure. Fixing controls during an incident costs several times what fixing them on a planned schedule costs, and the fixes are worse.

The legacy data problem. Pre-existing personal data is not grandfathered. Organisations that discover this in early 2027 will be re-papering consent and re-architecting retention against a deadline.

The gaps we see most often

The pattern is consistent. These are process and ownership failures wearing technical clothing. The controls usually exist. The evidence does not.

How Qualysec Accelerates Your DPDP Security Validation

Qualysec is a specialised penetration testing company. What we do in a DPDP context is validate whether the Rule 6 safeguards you have implemented actually hold, and produce the evidence in a form your auditor or the Board can read.

End-to-end penetration testing

Automation clears the mechanical layer early, covering known CVEs, missing headers, TLS configuration and common misconfigurations, so senior tester hours are not consumed by findings a scanner handles well. Certified consultants then spend the bulk of the engagement on the classes that tooling structurally cannot reach.

For DPDP specifically, that means object-level authorisation across roles and tenants, masking verified at the API rather than the interface, and business logic abuse in flows that move personal data.

The gap is not theoretical. On a recent engagement with a regulated financial platform preparing for a regulatory submission, the application passed automated scanning with no critical authorisation findings. Our consultants opened two separately funded accounts and began substituting object identifiers by hand. The wallet endpoint accepted a transaction identifier as an API parameter and never verified it belonged to the authenticated caller. Incrementing it returned another customer’s balance, transaction history and metadata, with sequential identifiers making the entire customer base enumerable.

That was one of 18 findings in that engagement, alongside source code disclosure through unhandled stack traces, an open redirect usable for phishing from the client’s own domain, missing anti-CSRF protection on account settings, and session tokens that survived a password change.

Under DPDP, that single authorisation flaw is a Section 8(5) failure and, if exploited, a reportable personal data breach under Rule 7.

Advanced API and cloud auditing

APIs are where masking fails and where object-level authorisation is either enforced or not. We test them directly rather than through the interface, because the interface hides nothing from a direct caller.

Cloud auditing covers the controls. Rule 6 names the environment where most Indian personal data actually sits: storage bucket exposure, IAM policy scoped to least privilege, encryption at rest across databases, snapshots and backups, key management and rotation, logging coverage and retention configuration, and data residency verified against actual region settings rather than stated intent.

That last item regularly catches organisations. The policy claims localisation, but a backup bucket replicates to a foreign region because someone enabled it years ago.

Compliance readiness reports

Findings arrive mapped to the obligation you are evidencing rather than to a generic OWASP reference, so the report enters your evidence pack directly instead of needing translation.

Each finding carries severity, reproduction steps written for the engineer shipping the patch, business impact stated in DPDP terms where relevant, and remediation guidance. False positives are removed before delivery. Reports are structured to satisfy 52-plus compliance frameworks, so one engagement can serve DPDP alongside ISO 27001, SOC 2 or your sectoral obligation.

Progress is visible live through the Qualysec Vulnerability Dashboard, and retesting is included as standard rather than invoiced separately, because a finding marked closed without independent verification is not closed.

Qualysec has delivered over 2,500 penetration test reports to 350-plus clients across 38 countries and holds CREST accreditation alongside ISO/IEC 27001:2022, ISO 9001:2015 and ISO 13485:2016.

One note on scope: This guide spends several sections telling you to interrogate vendors. Qualysec is a testing firm, not a legal advisory or a managed security provider. We do not draft your privacy notices, determine your lawful basis, or run your SOC. What we do is establish whether the controls behind your compliance claims hold.

Need a Pen Test?

Talk directly with senior security experts. Book a quick call or grab a quote today.

Get a Quote →

Conclusion

The organisations that will struggle with DPDP are not those with weak security, but those with undocumented security. They are the ones with undocumented security.

They encrypt but cannot produce the configuration export. Such organizations restrict access but have no recertification records. Those businesses have a breach plan, written in 2024, never exercised out of hours. The controls exist. The evidence does not exist, and Rule 6 is written so that evidence is the unit of compliance.

Three things are worth acting on now rather than in 2027.

Map before you build. Every technical obligation downstream depends on knowing where personal data lives. A reconciled inventory with owners is the prerequisite, and it takes longer than any control on the list.

Test the two controls nobody tests. Erasure completeness and consent withdrawal propagation are DPDP-specific; they are almost universally incomplete, and they will not appear in a standard penetration test scope unless you ask for them.

Generate evidence continuously. Configuration exports, access reviews, restore test results and log samples, produced as a by-product of operations and indexed by Rule. Reconstructed evidence never has accurate dates, and auditors notice.

The deadline is 13 May 2027; the runway was always going to feel shorter than eighteen months, and the engineering half of this work cannot be compressed the way documentation can.

If you want to know whether the safeguards behind your DPDP position actually hold, talk to our team about a Rule 6-aligned assessment, or review a sample report to see how findings are mapped.

Frequently Asked Questions

Does DPDP apply to employee and HR data?

Yes. Employee data is personal data, and your organisation is the Data Fiduciary for it. The Act does provide for certain processing for employment purposes among its listed legitimate uses, which means consent is not always the required basis, but the security safeguards under Section 8(5) and Rule 6 apply in full regardless of the lawful basis. HR systems, payroll, background verification records and performance data all belong in your data inventory.

Is ISO 27001 or SOC 2 certification enough for DPDP compliance?

No, though neither is wasted. DPDP obligations extend well beyond security into consent, notice, data principal rights, erasure and breach notification, none of which are necessarily covered by an ISO or SOC 2 scope. What certification does give you is a strong argument that your safeguards were reasonable, because alignment with recognised frameworks is one of the factors likely to inform how the Board assesses that standard. The efficient approach is evidence reuse: one control set, mapped to Rule 6, ISO 27001 Annex A and the SOC 2 criteria simultaneously.

Does the DPDP Act require data localisation?

Not as a blanket rule, and this is widely misstated. The Act permits transfer of personal data outside India except to countries the Central Government restricts by notification. This is a negative-list approach, not a localisation mandate. Two qualifications matter. Significant Data Fiduciaries may face restrictions on transferring specified categories of data, and sectoral regulators impose their own localisation requirements independently, most notably RBI for payment system data. Check the current notified position before relying on these rules, because the restricted list can change.

Does DPDP apply to B2B business contact data?

Yes, more often than B2B companies assume. A named individual’s work email address, direct line and job title are data about an identifiable individual, and the Act makes no exception for a business context. If you run outbound sales, maintain a CRM of prospect contacts, or operate a marketing database of professionals, that data is in scope. The listed legitimate uses may support some processing without consent, but notice obligations, data principal rights and the Rule 6 safeguards apply to it.

How does DPDP interact with RBI, SEBI and IRDAI requirements?

They stack rather than substitute, and the interaction creates real tension. DPDP requires erasure when the purpose is served, while RBI and SEBI mandate retention of certain records for defined periods. Rule 6 itself acknowledges this, requiring one-year log retention unless a longer period is required under another law. The practical approach is to build a retention matrix per dataset that records both the DPDP position and the sectoral requirement, and to document the reasoning where the longer period governs. Sectoral testing and audit obligations, such as CERT-In empanelled audits under RBI and SEBI frameworks, remain separate requirements that DPDP neither replaces nor satisfies.

Do we need to appoint a Data Protection Officer?

Only Significant Data Fiduciaries must appoint a DPO, who must be based in India and report to the board or governing body. Every other Data Fiduciary needs a published contact point for grievances and data principal requests, which can be a designated person or a role-based channel. That distinction saves smaller fiduciaries an unnecessary hire, so establish your designation status before recruiting.

What happens to personal data we collected before the Act came into force?

It is not grandfathered. Existing personal data remains subject to the Act, and notice obligations extend to data principals whose data you already hold. For most organisations this is a substantial and under-scoped workload: identifying legacy datasets, establishing a lawful basis for continued processing, issuing notice where required, and deciding what to erase. Start this early, because it takes longer than the technical controls.

How long do we have to respond to a data principal’s request?

Rule 14 caps grievance redressal at a reasonable period not exceeding 90 days. You must publish your response timeline, the procedure for making requests, and the identifiers required to verify the requester. Ninety days is a ceiling rather than a target, and a request that takes the full period will look poor if it later reaches the Board. Build the workflow with acknowledgement, tracking and internal escalation rather than treating 90 days as the service level.