For every technical security safeguard the DPDP Act asks a data fiduciary to take, this handbook gives you the plain-English answer first, then the evidence behind it: the concrete cloud-configuration fact that proves the safeguard is in place, and the scanner check that verifies it. It covers the engineering half of DPDP. The legal half (consent, notice, data-principal rights) belongs to your law firm.
This handbook evidences and demonstrates the technical safeguards under §8. It does not make you, or your client, "DPDP compliant" and the scanner does not certify compliance. It proves that specific controls are in place. Compliance is a legal determination made by a person, not a scan. Every control below is written to be read on its own. If you quote a single answer to a client, it should stay true and stay honest without the rest of the page.
A word on why the technical half matters, and why you are the right person to carry it. DPDP §8(5) requires a data fiduciary to take reasonable security safeguards to prevent a personal data breach. The penalty schedule attaches up to ₹250 crore to a failure of that duty, the highest tier in the Act. That is not a documentation exercise your client can wave a policy PDF at. It is a question about the actual state of the systems that hold personal data, and it is exactly the kind of technical question your client will ask you to answer for them. This handbook is about proving that state with facts, so you can give your client a straight answer instead of a hedge.
Each entry below is a question your client (or their auditor) actually asks, answered the way you would answer it, followed by the DPDP clause it rests on, what the check looks for in plain terms, and the Juro rule id that verifies it, for anyone who wants to trace the citation.
1. Access Control and Identity
The most common way personal data leaks is not a broken encryption algorithm. It is an identity that could reach the data and should not have been able to. DPDP §8(5) requires reasonable security safeguards, and Schedule 1 to the Act names access control and authentication among them. Access is the first safeguard any auditor will ask your client to evidence, and the first thing you should be able to answer for them without reaching for a spec sheet.
Are root access keys a DPDP problem?
Yes, and it's a serious one. A cloud root or owner identity bypasses every permission boundary your client has set up. If that key leaks, it isn't a partial breach, it's everything, including the personal data. Tell your client: no active access keys on the root account, full stop. Programmatic access should always run through scoped, least-privilege roles.
- DPDP basis
- §8(5), reasonable security safeguards.
- What to check
- the account has no active root access keys; every automated process authenticates through a scoped role instead.
- Verified by
- rule AWS-IAM-ROOT-001, which flags an IAM root account still carrying active access keys, cited to DPDP §8(5).
Does DPDP require MFA?
Effectively, yes. A password alone is not a reasonable safeguard for access to personal data in 2026, and Schedule 1 lists multi-factor authentication among the safeguards expected. If your client's login flow only asks for a password, that's a gap you can name specifically, not just a vague "improve security" line item.
- DPDP basis
- Schedule 1 §4, authentication safeguards, supporting §8(5).
- What to check
- the identity provider or user pool fronting the application requires a second factor before granting access, not just a password.
- Verified by
- rule AWS-COG-MFA-001, which flags a Cognito user pool (AWS's user-login service) that does not require MFA, cited to DPDP Schedule 1 §4.
Does DPDP require you to rotate access keys?
Yes, as a lifecycle discipline, not a one-time setup. A service-account key that has sat valid and unrotated for a year is a standing risk, because nobody can say with confidence every place it has been copied to. Tell your client to put a bound on key age, not just a policy that keys exist.
- DPDP basis
- Schedule 1 §3, credential lifecycle management, supporting §8(5).
- What to check
- long-lived, user-managed keys are rotated on a bounded schedule, so no active key sits unrotated indefinitely.
- Verified by
- rule GCP-IAM-KEY-001, which flags a service account with user-managed keys older than 90 days, cited to DPDP Schedule 1 §3.
Is a public Kubernetes cluster endpoint a DPDP concern?
Yes. A Kubernetes control plane exposed to the whole internet is reachable by anyone, which is the opposite of the restricted access Schedule 1 §3 expects for systems that touch personal data. This is a common gap in fast-moving engineering teams and worth asking about directly.
- DPDP basis
- Schedule 1 §3, access controls, supporting §8(5).
- What to check
- the cluster API endpoint is private, or its public access is restricted to known networks rather than open to the world.
- Verified by
- rule AWS-EKS-PUB-001, which flags an EKS cluster (AWS's managed Kubernetes service) whose API server endpoint is publicly accessible, cited to DPDP Schedule 1 §3.
Can a publicly readable storage bucket count against DPDP?
Yes, directly. Access to personal data has to be restricted to identities that need it. A storage bucket that grants read access to all users, or to anyone with a link, has no access control at all on the data sitting inside it. This is one of the most common, and most damaging, findings in practice.
- DPDP basis
- Schedule 1 §3, access controls, supporting §8(5).
- What to check
- bucket-level access is not granted to allUsers or allAuthenticatedUsers, and resolves only to named principals.
- Verified by
- rule GCP-STORAGE-ACCESS-001, which flags a Cloud Storage bucket that grants access to all users or all authenticated users, cited to DPDP Schedule 1 §3.
2. Network Exposure and Public Access
Access control decides who may reach an identity. Network control decides what is reachable in the first place. DPDP §8(5) and Schedule 1 §3 both point at keeping the systems that process personal data off the open internet unless there is a specific reason for them to be on it. This is the section where you can quickly tell a client whether their infrastructure was built with data protection in mind or bolted together for speed.
Should databases holding personal data sit in a private subnet?
Yes. Network segmentation is one of the oldest, most basic technical safeguards, and §8(5) expects it. A data store sitting in a public subnet is one misconfigured rule away from being reachable from anywhere on the internet.
- DPDP basis
- §8(5), reasonable security safeguards.
- What to check
- workloads that process or store personal data run in private subnets with no direct route to or from the public internet.
- Verified by
- rule AWS-VPC-PRI-001, which flags data-processing workloads placed in public subnets, cited to DPDP §8(5).
Is unrestricted outbound network access a DPDP risk?
Yes, and it's an easy one to miss. A safeguard isn't only about who gets in, it's also about where data can go once inside. A workload that can send traffic to any destination on the internet has no boundary on where personal data ends up if that workload is ever compromised.
- DPDP basis
- §8(5), reasonable security safeguards.
- What to check
- security groups on personal-data workloads restrict egress to known destinations rather than allowing all outbound traffic.
- Verified by
- rule AWS-SG-EGR-001, which flags a security group that permits unrestricted outbound access, cited to DPDP §8(5).
What does DPDP expect from firewall rules?
Rules scoped to known sources, not the whole internet. Schedule 1 §3 expects reasonable safeguards against unauthorised access. A firewall rule that opens a port to 0.0.0.0/0 is an invitation, not a safeguard, no matter what else is configured behind it.
- DPDP basis
- Schedule 1 §3, safeguards against unauthorised access, supporting §8(5).
- What to check
- firewall rules do not allow ingress from 0.0.0.0/0 to sensitive ports; access is scoped to known source ranges.
- Verified by
- rule GCP-VPC-FW-002, which flags overly permissive firewall rules allowing unrestricted ingress, cited to DPDP Schedule 1 §3.
Should Kubernetes nodes have public IP addresses?
No. Schedule 1 §3 expects network-level isolation for systems that handle personal data, and cluster nodes with public IPs expand the reachable surface of workloads that may be processing it.
- DPDP basis
- Schedule 1 §3, network isolation, supporting §8(5).
- What to check
- the cluster uses private nodes with no public IP addresses; any needed node-to-internet traffic routes through controlled egress.
- Verified by
- rule GCP-GKE-NET-001, which flags a GKE cluster (Google's managed Kubernetes service) whose nodes are not private, cited to DPDP Schedule 1 §3.
3. Encryption in Transit and at Rest
Encryption is where "reasonable safeguards" stops being an abstract phrase and becomes a concrete yes-or-no. DPDP §8(5) and Schedule 1 §3 expect personal data to be protected both while it moves across a network and while it sits on a disk. There's a short, honest note on citation tagging at the end of this section that you should read before quoting the last entry to a client.
Does DPDP require HTTPS or TLS for data in transit?
Yes. Personal data moving between a user and your client's service, or between their own internal services, should never travel as plaintext. §8(5) treats encryption in transit as a baseline technical safeguard, not an advanced one.
- DPDP basis
- §8(5), safeguards for personal data in transit.
- What to check
- the content delivery or edge layer enforces a modern TLS policy and rejects plaintext or deprecated protocol versions.
- Verified by
- rule AWS-CF-TLS-001, which flags a CloudFront distribution (AWS's content-delivery network) permitting weak or outdated TLS, cited to DPDP §8(5) and, for the same underlying control, GDPR Art. 32.
Does a managed database need encrypted connections under DPDP?
Yes. A managed database that accepts unencrypted connections lets personal data cross the network in the clear between the application and the database itself. Schedule 1 §3's encryption standards apply to that path, not just to the disk the data eventually lands on.
- DPDP basis
- Schedule 1 §3, encryption standards, supporting §8(5).
- What to check
- the database instance requires SSL or TLS for all client connections and rejects unencrypted ones.
- Verified by
- rule GCP-SQL-ENC-001, which flags a Cloud SQL instance that does not enforce encrypted connections, cited to DPDP Schedule 1 §3.
Do secrets and parameters need customer-controlled encryption keys?
Yes, if your client wants to be the one who actually controls access. The secrets that unlock personal data, database passwords, API keys, are themselves sensitive. §8(5) treats their protection as part of the safeguard. A customer-managed key means your client, not only the cloud platform, governs who can decrypt them.
- DPDP basis
- §8(5), reasonable security safeguards.
- What to check
- secure parameters and secrets are encrypted with a customer-managed key rather than only a default platform key.
- Verified by
- rule AWS-SSM-CMK-001, which flags SSM parameters (AWS's parameter and secrets store) not encrypted with a customer-managed key, cited to DPDP §8(5).
Is personal data encrypted at rest, and how does DPDP read that check?
Yes, it needs to be, everywhere personal data is stored: object storage, databases, and warehouses alike, and the keys that protect it need scoped access too. Encryption at rest is a core §8(5) safeguard, and it's usually the first thing a client assumes is already handled. It's worth confirming rather than assuming.
- DPDP basis
- §8(5), reasonable security safeguards, evidenced through encryption at rest.
- What to check
- buckets, databases, warehouses, and the keys that protect them all enforce encryption at rest, with key access policy scoped rather than open.
- Verified by
- rules AWS-S3-ENC-001 (object storage), AWS-RDS-ENC-001 (relational databases), AWS-KMS-POL-001 (key access policy, via KMS, AWS's key-management service), GCP-STORAGE-ENC-001 (object storage), and GCP-BQ-ENC-001 (data warehouse), each verifying encryption at rest for its store.
in the scanner today, these five checks carry a GDPR Art. 32 legal basis, encryption of personal data, which is the same safeguard DPDP asks for. The scan output for these five does not yet print a DPDP tag directly. The at-rest encryption control they verify is the same technical fact that evidences DPDP §8(5), and a DPDP citation crosswalk is the source of truth mapping them across. Read them as evidence of the safeguard. The DPDP tag can be added to the scan output when a customer or partner needs the report itself to carry it. Don't read the current scan output as showing a DPDP citation for these five, and don't represent it that way to a client either.
4. Logging and Audit Trails
You cannot prove a safeguard held if there was no record of who touched the data. DPDP §8(5) carries an accountability dimension: a data fiduciary should be able to reconstruct access to personal data stores after the fact. This is the section that turns "we believe our systems are secure" into "here is the record that shows it."
Does DPDP require logging access to personal data stores?
Yes. An audit trail of who read or changed personal data is what lets your client answer, after the fact, whether an access was legitimate. §8(5) treats that trail as a technical accountability measure, not an optional nicety.
- DPDP basis
- §8(5), accountability and record-keeping.
- What to check
- data-plane event logging is enabled on the stores that hold personal data, capturing object-level and record-level access.
- Verified by
- rule AWS-CT-DATA-001, which flags missing CloudTrail data-event logging (AWS's activity-logging service) on personal data stores, cited to DPDP §8(5).
Should you have automated alerting on your logs?
Yes. A log nobody watches is a record for the post-mortem, not a safeguard in the moment. §8(5)'s reasonable safeguards include noticing a problem while it's happening, and automated metric filters and alerts are what turn a passive log into active detection.
- DPDP basis
- §8(5), reasonable security safeguards.
- What to check
- metric filters and alarms are configured on the log groups that matter, so anomalous activity raises an alert instead of sitting silently.
- Verified by
- rule AWS-CWL-MF-001, which flags log groups without the expected metric filters and alerting, cited to DPDP §8(5).
Does DPDP expect audit logs to be centralised and retained?
Yes. Audit records scattered across projects, or discarded quickly, cannot support accountability. §8(5)'s record-keeping expects logs to be routed to durable storage where they survive long enough to be reviewed when it matters.
- DPDP basis
- §8(5), accountability and record-keeping.
- What to check
- an audit log sink exports logs to durable, centralised storage rather than leaving them to expire in place.
- Verified by
- rule GCP-AUDIT-SINK-001, which flags a missing or misconfigured audit log sink, cited to DPDP §8(5).
5. Retention and Deletion
Holding personal data longer than necessary is its own risk. DPDP §8(3) sets a retention limitation, and §8(9) requires that personal data not be kept beyond the period necessary. This is a section clients tend to underestimate, because "we'll delete it eventually" is not the same as an automated rule that actually fires.
Does DPDP require you to delete data you no longer need?
Yes, and it needs to be automatic, not a manual promise. §8(9) says personal data must not be retained beyond the period necessary. A bucket that keeps every object forever has no retention limit at all, regardless of what the policy document says. An automated lifecycle policy is the technical safeguard that actually enforces the limit.
- DPDP basis
- §8(9), retention limitation, safeguarded under §8(5).
- What to check
- object storage holding personal data carries a lifecycle policy that expires or transitions objects on a defined schedule.
- Verified by
- rule AWS-S3-LCP-001, which flags an S3 bucket without a lifecycle policy, cited to DPDP §8(9).
Should warehouse tables expire personal data automatically?
Yes. A data warehouse is where personal data quietly accumulates over years of pipelines and dashboards. §8(3)'s retention limitation expects a bound on how long it stays, and table or partition expiry is the technical form that bound takes.
- DPDP basis
- §8(3), retention limitation.
- What to check
- warehouse datasets and tables holding personal data have a default expiry configured, so old rows age out instead of piling up indefinitely.
- Verified by
- rule GCP-BQ-EXPIRY-001, which flags BigQuery datasets or tables (Google's data warehouse) with no expiry configured, cited to DPDP §8(3).
Does DPDP expect a defined retention setting on storage?
Yes, and it cuts both ways. Your client needs data to age out when it's no longer needed, and needs that behaviour to be a deliberate, documented setting rather than whatever the default happened to be. §8(3) expects the retention behaviour itself to be defined, not accidental.
- DPDP basis
- §8(3), retention limitation.
- What to check
- storage buckets holding personal data have a retention configuration reflecting a deliberate policy, not an unbounded default.
- Verified by
- rule GCP-STORAGE-RETAIN-001, which flags storage buckets without a defined retention configuration, cited to DPDP §8(3).
6. Backup, Resilience and Breach Detection
We'll say this plainly, and you should say it plainly to a client too: this section is thin. The scanner has early coverage here, not a full resilience posture. DPDP §8(7) speaks to the accuracy and recoverability of personal data, and §8(5) to detecting unauthorised access. What follows evidences pieces of that, not the whole of it, and you should represent it that way rather than as complete backup assurance.
Does DPDP require backups of personal data?
Yes, in the sense that recoverability is a legal expectation, not just good practice. §8(7) speaks to keeping personal data accurate and recoverable. If a store is lost or corrupted and there's no backup, recoverability has already failed. Backup readiness is the technical safeguard behind that requirement.
- DPDP basis
- §8(7), recoverability, safeguarded under §8(5).
- What to check
- critical data stores are covered by an active backup plan rather than left with no recovery path.
- Verified by
- rule AWS-BKP-EMP-001, which flags an empty or absent backup plan on resources that should be protected, cited to DPDP §8(7).
Is object versioning relevant to DPDP?
Yes, in a narrower way than backups. §8(7) expects personal data to stay complete and accurate. Versioning protects against an accidental or malicious overwrite silently destroying the correct version of a record, which is a recoverability safeguard in its own right.
- DPDP basis
- §8(7), completeness and accuracy.
- What to check
- buckets holding personal data have versioning enabled, so an overwrite or delete leaves a recoverable prior version.
- Verified by
- rule AWS-S3-VER-001, which flags an S3 bucket without versioning enabled, cited to DPDP §8(7).
Does DPDP expect threat detection on data stores?
Yes. §8(5)'s reasonable safeguards include noticing unauthorised access to personal data stores while it's happening. Threat detection tuned to those stores is how suspicious access becomes an alert instead of an unnoticed event discovered weeks later.
- DPDP basis
- §8(5), detection of unauthorised access.
- What to check
- managed threat detection is enabled and configured to monitor the storage that holds personal data.
- Verified by
- rule AWS-GD-S3-001, which flags GuardDuty (AWS's threat-detection service) not being configured to monitor S3 data stores, cited to DPDP §8(5).
7. Advisory: outside the scanner
The two subsections below are not scanner output, and you shouldn't present them to a client as if they were. They are the two honest gaps where DPDP asks for something the scanner does not, and should not, try to detect. We name them rather than skip them, because a named gap routed to the right partner is more useful to a client than a silent omission that surfaces later as a surprise. Everything in Section 7 is advisory. It's also, not coincidentally, exactly where a CA firm or DPO consultancy earns its fee.
7a. Processor and Vendor (DPA) obligations. Advisory.
This is a contract and governance question, not a technical one, and it's squarely yours to own. Where a data fiduciary engages a processor to handle personal data on its behalf, DPDP expects that relationship to be governed by contract, with the processor bound to appropriate obligations.
- DPDP basis
- Processor and data-processing-agreement obligations between a data fiduciary and the data processors it engages.
- What proves it
- Signed data-processing agreements, a maintained vendor register, and contractual controls flowed down to each processor. None of that is a cloud-configuration fact, so the scanner has zero technical coverage here, by design.
- Where this goes
- You. This is exactly the hand-off surface a DPO consultancy or CA firm is built to own, and exactly where you tell your client the scan stopped and your advisory work starts.
7b. Breach notification to the Board and data principals (§8(6)). Advisory.
Also yours, and time-sensitive. On a breach, §8(6) requires notification to the Data Protection Board and to affected data principals within the statutory process and timelines. The penalty schedule attaches up to ₹200 crore to a failure of this duty, so it isn't a formality your client can defer to "later."
- DPDP basis
- §8(6), the duty to notify the Data Protection Board and affected data principals of a personal data breach.
- What proves it
- A documented breach-response runbook, defined notification timelines, and evidence that the process has actually been exercised. The scanner can help detect a breach (Section 6 covers pieces of that detection), but the duty to notify is a legal and operational process, not a configuration state.
- Where this goes
- You, paired with your client's incident-response process.
How to verify these yourself, or on behalf of a client
Every control in Sections 1 through 6 maps to a real check that runs against a real cloud account. The one validated way to see the results, your own or your client's, is the live scan.
- Go to jurocompliant.com and run a scan against the environment in question.
- The scan reports which of these checks pass and which do not, each with its cited legal basis, so you and your client get evidence rather than a claim.
- Read the output the way this handbook is written, and hand it to a client the same way. A passing check evidences a specific technical safeguard under §8. It does not, on its own, make anyone DPDP compliant, and it is not a certificate. It is proof that a named control is in place, which is the part an auditor, a customer, or the Board will ask to see.
For the two advisory items in Section 7, and for the legal half of DPDP that sits outside any scanner, that's your lane. The technical evidence in this handbook is designed to sit alongside your advisory work, not to replace it, and to give you something concrete to hand your client instead of a general assurance.
Run the DPDP technical evidence scan
Juro scans a public surface and cloud infrastructure against each control in this handbook and reports which pass, each with its cited legal basis. No account required to see public-surface results, yours or a client's.
Scan an environment →This handbook is the engineering half of DPDP §8. For processor agreements, breach notification process, and the legal half of DPDP (consent, notice, data-principal rights), that's your lane — see Section 7.
References
- DPDP Act 2023: Ministry of Electronics and Information Technology
- DPDP Rules 2025: Official Gazette Notification — MeitY
- Ministry of Electronics and IT: meity.gov.in
About Juro: Juro scans for DPDP, GDPR, and DORA obligation markers in public-facing assets and cloud infrastructure, and generates signed, verifiable scan artifacts. It detects and evidences gaps and controls — it does not certify compliance. Note: jurocompliant.com is a compliance scanning tool — not juro.com, which is a contract management platform.