India's Digital Personal Data Protection Act has been in force long enough that engineering teams have stopped asking "does it apply to us?" and started asking "how do we actually operationalize the security safeguards?" For any organization processing personal data of individuals in India — which in practice means most global SaaS companies, many financial services platforms, and every domestic business at scale — the act's software security obligations are now a real engineering concern with real penalty exposure.
This is the view from implementation. If you've read the statute and the draft rules and are now trying to translate "reasonable security safeguards" into concrete technical controls, this is the conversion guide. The act is principle-based rather than prescriptive, which means the engineering response has to be defensible rather than merely compliant.
What does the DPDP Act actually require on security?
The act requires every data fiduciary to implement "reasonable security safeguards" to prevent personal data breaches, with heightened obligations for Significant Data Fiduciaries (SDFs) as notified by the central government. In 2026 practice, "reasonable" has been interpreted through a combination of the DPDP Rules, sectoral regulators (RBI for financial services, IRDAI for insurance, CERT-In for the broader ecosystem), and a growing body of Data Protection Board of India guidance.
The operational translation is: encryption of personal data in transit and at rest, access controls with auditability, monitoring sufficient to detect breaches, secure software development practices, and vendor due diligence. Each of these is where a "reasonable" program differs from a minimum-compliance one. A reasonable access control program has just-in-time elevation, continuous audit logging, and periodic access reviews; a minimum one has RBAC and an annual certification.
Breach notification is a specific, timebound obligation. Personal data breaches must be reported to the Data Protection Board and affected individuals without undue delay, with the CERT-In reporting obligations layering on top for certain categories of incident. The 2026 expectation is notification inside six hours for the CERT-In-eligible events, and your engineering detection capabilities need to support that cadence.
Who qualifies as a Significant Data Fiduciary and what changes?
The central government designates SDFs based on volume and sensitivity of personal data processed, risk to electoral democracy, security of the state, and public order. In 2026, the notified SDF categories include large social media intermediaries, major e-commerce platforms, payments operators, large credit bureaus, and health data processors above certain thresholds. If you fit any of these profiles — even as a subsidiary or regional entity of a global business — you need to plan for SDF obligations.
SDFs have additional obligations that ripple into engineering: mandatory appointment of a Data Protection Officer based in India, periodic data protection impact assessments, independent data audits, and algorithmic governance for systems that process personal data at scale. The DPIA and audit requirements in particular drive engineering evidence production. Your systems need to produce artifacts — data flow diagrams, processing logs, consent records, retention enforcement records — that an external auditor can examine and sign off.
Cross-border transfer restrictions also apply more stringently to SDFs. Data can be transferred outside India only to jurisdictions not restricted by the central government, and SDFs bear a heavier accountability for validating the transfer arrangements. In practice, most SDFs are building India-resident data infrastructure for the sensitive categories, with clearly documented transfer paths for the rest.
What do "reasonable security safeguards" look like in engineering terms?
Start with data classification. You cannot protect what you haven't labeled. Every data store, every API, every log stream should have a classification indicating whether it carries personal data and at what sensitivity. The classification drives the controls: encryption standards, access scope, retention period, and monitoring intensity.
Encryption is the most-scrutinized control because it's concrete and testable. In transit means TLS 1.2 or higher with modern cipher suites; most regulators are coalescing around TLS 1.3 for new systems. At rest means AES-256 or equivalent, with key management that supports rotation, auditing, and separation of duties between key administrators and data access. For SDFs, expect questions about HSM-backed key storage for the highest-sensitivity data.
Access control must be evidence-producing. Every access to personal data should be logged with the user identity, the timestamp, the data scope accessed, and the business justification. The logs need to be tamper-resistant and retained for a defined period (CERT-In rules require 180 days minimum for many log categories; sectoral regulators often require longer). Log volume at scale is an engineering challenge that benefits from structured logging and efficient log pipelines; retrofitting is painful.
How should breach detection and notification actually work?
Breach detection is about reducing the time between compromise and awareness. The detection stack needs coverage at multiple layers: network-level anomaly detection, host-level monitoring for unusual processes or file access, application-level detection for abnormal data access patterns, and external detection for leaked data appearing on the dark web or paste sites. No single layer catches everything.
Notification workflow has to be automated enough to hit the timelines. When a breach is confirmed, the workflow should: scope the affected data (which individuals, which data categories, which jurisdictions), generate the regulator notification draft, alert the DPO and legal counsel, and initiate the affected-individual notification process. Manual workflows routinely miss the six-hour CERT-In window and the "without undue delay" expectation for the Data Protection Board.
Practice the workflow. Tabletop exercises at least quarterly, with specific scenarios (insider access abuse, credential compromise, vendor breach, ransomware) and measurable outcomes. The first time you run the real workflow should not be the first time you've run it at all. Teams that drill breach response consistently hit their notification windows; teams that don't routinely miss them.
What vendor and third-party obligations matter?
The act places accountability on the data fiduciary regardless of whether the breach originated at a data processor. Your vendor agreements need to include data protection terms that flow down your security and notification obligations, audit rights, and specific SLAs for vendor-side incident reporting to you. A vendor that takes 48 hours to notify you of a breach effectively prevents you from hitting your own regulator notification windows; the contractual fix is explicit.
Vendor due diligence expectations have tightened in 2026. A questionnaire-based process is no longer sufficient on its own for vendors handling sensitive personal data. Expect to be asked to show evidence of your vendor's controls: SOC 2 reports, ISO 27001 certificates, independent security assessments, and increasingly SBOMs for the software the vendor provides. For SDFs, the vendor review needs to be refreshed continuously rather than on a standing annual cycle.
Subprocessor management is the piece most TPRM programs handle weakly. Your vendor's subprocessors are, transitively, processing your data. The act expects awareness of the chain and accountability for its posture. Build your TPRM data model to support nested subprocessor visibility, or accept that you'll have gaps a determined regulator will find.
How does software supply chain security intersect with DPDP?
The act doesn't explicitly mandate SBOMs or software supply chain controls, but "reasonable security safeguards" in 2026 includes visibility into the components processing personal data. A known vulnerability in a widely-used library that handles personal data, left unpatched because the engineering team didn't know they were using the library, will not survive a Data Protection Board investigation as "reasonable."
Practically, this means SBOMs for every system that processes personal data, with vulnerability management tied to the SBOM output. Reachability analysis is the force multiplier: a reported CVE in a component that's in your tree but not reachable from a personal data processing path has a different priority than one that sits on the request-handling critical path.
Breach investigation also benefits from SBOM posture. When you're trying to determine whether a specific CVE was the vector, you need to know whether the affected version was present, whether it was reachable, and whether your runtime telemetry shows exploitation attempts. Teams that instrument this in advance respond to incidents in hours; teams that don't spend days on forensic reconstruction.
How Safeguard.sh Helps
Safeguard.sh maps every system processing personal data to its SBOM and produces the inventory evidence a Data Protection Board investigator or an SDF auditor expects to see. Griffin AI applies reachability analysis at 100-level depth so your "reasonable safeguards" narrative can distinguish which vulnerabilities actually sit on personal data paths, sharpening both remediation priority and breach impact analysis. Eagle watches CERT-In advisories, CVE feeds, and leaked-credential surfaces continuously and feeds events into your breach detection and notification workflow, supporting the six-hour CERT-In window and the "without undue delay" DPB expectation. The TPRM module tracks vendor and subprocessor posture with the depth SDFs need for their DPIA and audit obligations, producing machine-verifiable evidence rather than questionnaire narratives. Container self-healing rebuilds and redeploys affected services when a supply chain vulnerability requires remediation, keeping the personal data processing surface aligned with your stated DPDP safeguards.