DPDP Act Cybersecurity Obligations: What CISOs Need to Know

The DPDP framing: fiduciary, principal, and personal data

The Digital Personal Data Protection Act, 2023 organises itself around three roles. The Data Principal is the individual to whom the personal data relates. The Data Fiduciary is the entity that determines the purpose and means of processing that data, and carries the primary compliance burden. A Data Processor acts on the Fiduciary's behalf under contract.

For a security team, the practical translation is simpler than the legal language suggests: if your organisation collects, stores, or processes data that identifies a person, whether that is a customer record, an employee HR file, or a transaction log tied to an account, your organisation is very likely acting as a Data Fiduciary for that data, and your security controls around it are now part of a compliance surface, not just an operational one.

The Act also introduces the concept of Significant Data Fiduciaries, a category of entities that, based on volume and sensitivity of data handled, face additional obligations such as periodic audits and impact assessments. Whether your organisation falls into this category is a determination for legal and compliance teams, but security leaders should assume the possibility and build accordingly.

Why cybersecurity is implicit, not prescriptive, in DPDP

Unlike some international frameworks that specify control catalogues, the DPDP Act does not enumerate a list of required security controls. Instead, it uses a standard commonly summarised as 'reasonable security safeguards' to prevent personal data breaches. This is a deliberately flexible standard, and that flexibility is both an opportunity and a risk for CISOs.

The opportunity is that a risk-based, proportionate security programme is exactly what the standard rewards. The risk is that 'reasonable' will be judged retrospectively, after an incident, against what a comparable organisation in your sector was doing at the time. A programme that looks reasonable on paper but cannot produce evidence of its own operation will not hold up well under that kind of scrutiny.

• Reasonable safeguards are judged against sector norms and the sensitivity of the data involved, not against a fixed checklist.
• The absence of a prescriptive control list places more weight on documented risk assessments and demonstrable control coverage.
• Evidence of continuous operation, not just a written policy, is what distinguishes a defensible safeguard from a paper one.

Operational implications: the breach notification workflow

When a personal data breach occurs, the Act contemplates a notification workflow involving the Data Protection Board of India and, in relevant circumstances, the affected Data Principals. The exact triggers, formats, and timelines for these notifications are set out in the Act and its rules, and continue to be clarified through subsequent notifications and Board guidance, so CISOs should track the current rules rather than relying on this article for specifics.

What is stable, regardless of the exact wording of a future rule, is the operational sequence a security team needs to be able to execute: detect the incident, assess whether personal data was affected and to what extent, determine the likely harm to Data Principals, and prepare the internal record that supports whatever notification decision is made. Building this sequence into your incident response playbook now removes the scramble later.

• Detection: how quickly can the SOC establish that an incident involves personal data, not just infrastructure?
• Harm assessment: what categories of data were exposed, and what is the realistic impact on affected individuals?
• Board interface: who owns communication with the Data Protection Board, and what evidence package do they need on short notice?
• Principal notification: what is the trigger for informing affected individuals, and who drafts and approves that communication?

The interplay with CERT-In directions

DPDP obligations do not exist in isolation. CERT-In's directions on cybersecurity incident reporting already require covered entities to report specified categories of incidents within a defined window, and separately mandate log retention for a defined period within Indian jurisdiction. These obligations predate DPDP and run in parallel to it.

In practice, a security incident that triggers a DPDP-relevant breach assessment will very often also trigger a CERT-In reporting obligation, and the log retention requirements under CERT-In directions become the evidentiary backbone for both. A CISO who treats these as two separate compliance tracks, run by two separate teams with two separate log stores, is building unnecessary friction and risk of inconsistency into incident response. Treating them as a single evidence and reporting pipeline, with CERT-In timelines as the tighter operational constraint, is the more resilient design.

The intersection with sectoral regulators

For regulated sectors, DPDP is not the only, or even the primary, cybersecurity-adjacent framework in play. The Reserve Bank of India has its own cybersecurity and resilience frameworks for banks, NBFCs, and payment system operators. IRDAI has issued information and cybersecurity guidelines for insurers. SEBI has cybersecurity and cyber resilience frameworks for market infrastructure institutions and intermediaries.

Where these sectoral frameworks are more specific than DPDP's general safeguard standard, they typically set the operational floor for what a security programme must do, while DPDP adds the personal-data-breach notification and governance layer on top. A financial-sector CISO should map controls to the sectoral regulator's framework first, then verify that the DPDP breach and governance obligations are integrated into the same incident response and audit structure, rather than bolted on separately.

Data sovereignty and cross-border processing

The DPDP Act permits cross-border transfer of personal data except to countries restricted by the Central Government, a materially more permissive default than some earlier draft versions of Indian data protection law proposed. That said, sector-specific rules from RBI and others can still impose stricter localisation requirements for particular categories of data, and government notifications can add restricted jurisdictions over time.

For security programmes specifically, there is a less discussed sovereignty question: security telemetry, logs, alerts, and incident investigation records are frequently adjacent to personal data even when they are not the primary personal data record itself. A log line that includes a customer ID, an email address, or a transaction reference is personal-data-adjacent, and if that telemetry is processed by a security tool whose analysis or model inference happens outside your jurisdiction, you have extended your cross-border footprint without necessarily making an explicit decision to do so. CISOs evaluating security platforms should ask directly where the analysis actually happens, not just where the vendor's headquarters are.

A practical CISO checklist

The following checklist reflects the operational themes above, structured as a starting point for a working session with legal and compliance rather than a final control list.

• Data mapping: maintain a current inventory of where personal data lives, including in logs, backups, and analytics pipelines, not just primary databases.
• Retention: align retention schedules for personal data and adjacent security telemetry with both DPDP purpose-limitation principles and CERT-In's log retention requirements.
• Access governance: enforce least-privilege access to systems holding personal data, with logging of access itself as an auditable control.
• Breach playbook: build a single incident response playbook that covers detection, harm assessment, CERT-In reporting timelines, and DPDP Board and Principal notification steps together.
• Evidence preservation: ensure incident investigation records, forensic images, and decision logs are preserved in a form that can be produced to regulators or auditors without reconstruction after the fact.
• Vendor and processor due diligence: confirm that Data Processors and security tool vendors can meet the same evidentiary and residency expectations you are held to.

Why an autonomous SOC helps meet timely-detection expectations

Every regulatory framework touched on above, DPDP's reasonable-safeguard standard, CERT-In's reporting windows, and sectoral resilience frameworks, shares an implicit assumption: that the organisation will know about an incident quickly enough to act on it. That assumption is where many security programmes quietly fail, not because controls are absent but because detection is slow, alert volume overwhelms analysts, and the record of what happened is scattered across tools.

An autonomous SOC that correlates telemetry continuously, triages at machine speed, and produces a structured, timestamped record of detection and response directly supports the timely-detection expectation embedded in these frameworks. It does not replace the human decisions around harm assessment or regulatory notification, but it removes the delay and evidence gaps that make those decisions harder to defend after the fact.

Where Spharaka Sphere and AirWatch fit

Spharaka Sphere supports sovereign deployment topologies, including SaaS in India, sovereign hybrid, and fully on-premise options, so that security telemetry adjacent to personal data can be kept within the boundary your programme requires. SAGE, the cybersecurity reasoning model at Sphere's core, runs within that deployment boundary rather than as calls to an external general-purpose API, which matters directly for the cross-border processing question above.

AirWatch focuses on the evidence side of the equation: it maintains auditable records of detection, decisioning, and response actions, the kind of structured evidence chain that supports both a CERT-In incident report and a DPDP breach assessment without separate reconstruction. Neither product is a compliance certification, and neither replaces the judgment of legal counsel or a compliance officer. What they provide is the architectural and evidentiary foundation that makes a 'reasonable security safeguards' argument credible when it is tested.