How to Prepare Your SAP Landscape for India's DPDPA

For more than two years, organizations knew India's new privacy law was coming. They attended webinars, reviewed legal updates, discussed compliance roadmaps, and waited for the operational details that would turn the Digital Personal Data Protection (DPDP) Act from legislation into reality.

That wait ended on 13 November 2025.

With the notification of the DPDP Rules, 2025, privacy compliance is no longer a future consideration. It is now a business responsibility that organizations must actively manage.

Many leaders assume that privacy compliance is simply about updating policies, publishing consent notices, or introducing a few new controls. In practice, it is much more complex.

Can your organization confidently identify every category of personal data it collects?
Can it explain why that data is being collected?
Can it demonstrate who has access to it, how long it is retained, and what happens when an individual asks for it to be corrected or erased?

For many organizations, the honest answer is "not completely."

That is where the real challenge begins.

The DPDP Rules are not just creating new compliance obligations. They are forcing organizations to take a hard look at how personal data flows through business processes, applications, vendors, cloud platforms, and day-to-day operations. Gaps that were previously hidden behind policy documents and spreadsheets are now becoming governance, operational, and regulatory risks.

The organizations that move early will have time to build sustainable privacy programs. Those that delay may find themselves trying to answer difficult questions from regulators, customers, partners, and employees without having the foundations in place.

The rules are here. The expectations are clear. The only uncertainty that remains is whether organizations are ready.

The timeline makes one thing clear: organizations have a finite window to prepare, but compliance cannot be achieved through policies and awareness sessions alone.

For SAP-centric organizations, the real challenge lies in translating the requirements of the DPDPA into practical controls across business processes, applications, users, and data flows. Personal data resides throughout the SAP landscape, from employee records in HCM and SuccessFactors to customer information in S/4HANA, CRM, Ariba, Concur, and numerous custom applications and integrations.

This is where many privacy programs encounter their first reality check. While the DPDPA is written as a technology-agnostic law, compliance ultimately depends on how personal data is collected, processed, accessed, retained, shared, and deleted within enterprise systems.

The question, therefore, is not whether your organization processes personal data. The question is whether your SAP landscape can demonstrate the controls, governance, and accountability that the DPDPA expects.

To answer that, it is important to understand what the DPDPA actually requires from an SAP environment.

What DPDPA actually requires from your SAP landscape

The Act grants every Data Principal (anyone whose personal data you process) a defined set of rights against the Data Fiduciary (you). Each right is a technical capability your SAP landscape must deliver. Not a policy statement, not a privacy notice. The configuration has to work.

Right	Section	SAP Implication
Access to information about personal data	§11	Information Retrieval Tool (IRT) across all in-scope systems
Correction, completion, updating, erasure	§12	Master data change documents + ILM blocking/deletion
Grievance redressal	§13	Workflow with tracked response timelines
Nomination	§14	Identity verification layer in grievance application
Withdraw consent	§6	Consent platform + EoP trigger in ILM

Two further obligations shape design just as forcefully, even though they are not technically “rights”:

Purpose and storage limitation (§§4, 5, 8): Data must be erased when its purpose ends or consent is withdrawn, unless law requires retention.
Breach notification (§8(6)): The Data Protection Board and affected Data Principals must be notified of breaches within the prescribed timeline.

Where personal data actually lives (build the inventory first)

Before touching a single configuration screen, map where personal data sits. Skipping this step is the single most common reason DPDPA programmes run into trouble. You cannot write sensible ILM rules for data you haven’t located.

In a typical Indian enterprise SAP estate, personal data concentrates in four domains:

Customer master in S/4HANA: Business Partner records – such as Customer names, addresses, contact details, tax identifiers, and bank account information.
Vendor master in S/4HANA: Individual contractors, freelancers, and consultants make vendor master the most personally dense corner of many finance landscapes. In one engagement, the vendor master held three times as many Data Principal records as the customer master.
Employee data in SuccessFactors: Employee Central, Recruiting, Onboarding, Performance and Goals, Compensation, Learning, and Succession together hold a richer personal data set than the rest of the SAP estate combined. Current employees, former employees, candidates, and named dependents are all Data Principals.
Replication targets and integrations: Personal data flows continuously from core systems to SAP Concur, SAP Ariba, payroll engines, tax platforms, banking integrations, and analytics. Every destination is in scope. This is also where most enforcement risk lives, because data crossing system boundaries is rarely as well-governed as data sitting in core.

Document this as a Record of Processing Activities. DPDPA does not use that exact term, but the Rules require equivalent documentation, and the discipline of a consolidated Record across every system is what makes all downstream configuration coherent.

The SAP capabilities that do the work

You do not need to build any of this from scratch. SAP has been refining data protection capabilities since 2017, driven by GDPR and the regulations that followed. The toolset is mature. The challenge in 2026 is correct configuration for the Indian regulatory context, not invention.

SAP Information Lifecycle Management (ILM) is the foundation. It defines and executes retention, blocking, and deletion rules on a schedule across S/4HANA and other NetWeaver-based systems. Read SAP Note 2590321 (Upgrade recommendations to support GDPR compliance) before starting.

Release recommendations have changed and you do not want to discover a stack mismatch after months of configuration work. Plan several months for a serious ILM implementation; a fortnight is not realistic.

End of Purpose (EoP) check is the gate that decides whether a master record is eligible for blocking. The check examines every transactional and contextual purpose attached to the record. If any purpose remains active (open sales order, pending invoice, ongoing employment), blocking cannot proceed and the Data Principal must be told why. The EoP logic is where most implementations spend the longest debugging time, because what counts as an “active purpose” is subtler than it looks in real business processes.

Simplified Blocking and Deletion is the two-stage execution pattern. Once EoP confirms expiry, blocking restricts access to a small set of privileged users (DPO, Finance, Audit). Operational users no longer see the data; reports exclude it. After the statutory retention period lapses (typically seven years for tax-relevant records in India), deletion is permanent. Block first, delete later. This reconciles the right to erasure with statutory retention obligations and is the correct pattern for almost every Indian SAP scenario.

Information Retrieval Tool (IRT) delivers the Right to Access under §11. It searches across in-scope modules for every record relating to a given Data Principal and consolidates the output. The §11 response is not a database dump. It is a summary a non-technical individual can actually read. Avoid the temptation to deliver 200-page Excel exports.

Read Access Logging (RAL) records who viewed which personal data, when, through which application, and for what declared purpose. RAL is the evidence layer that lets you demonstrate to auditors and the Data Protection Board that access has been controlled. The defaults are essentially nothing; every field, every channel, and every purpose must be configured explicitly. Scope it carefully: configured indiscriminately, RAL will generate log volumes that are more noise than signal.

Change Documents and the Security Audit Log (SAL) together provide the audit trail for corrections, erasures, and access events. Verify that change documents are active on every relevant master data object. Do not assume. Check.

SuccessFactors Data Protection and Privacy runs through a separate toolkit: Data Retention Management rules, Data Subject Information Reports, and the purge framework for terminated employees. The conceptual pattern mirrors S/4HANA. Every operational detail differs.

SAP Customer Data Cloud addresses consent management, the gap in the core SAP platform. For most employee and B2B scenarios, consent is not the legal basis for processing, which simplifies things considerably. For B2C-heavy organisations, Customer Data Cloud or an integrated third-party Consent Manager platform is the realistic path.

What happens if you don’t: penalties, liability, and who carries the risk

This is the section most compliance documents bury in an appendix, or skip entirely. It should be the first thing the CFO and Board see.

The penalty schedule is not theoretical

The Schedule to the DPDPA sets out maximum financial penalties per breach. These are absolute rupee amounts, not percentages of revenue. A small company and a large enterprise face the same ceiling. The Board determines the actual figure based on the nature and gravity of the breach, the volume and sensitivity of data affected, whether remedial action was taken promptly, and the organisation’s compliance history.

Violation	Maximum Penalty
Failure to implement adequate security safeguards (§8(5))	Up to ₹250 crore
Failure to notify the Board or Data Principals of a breach (§8(6))	Up to ₹200 crore
Non-compliance with children’s data provisions (§9)	Up to ₹200 crore
Failure to fulfil Significant Data Fiduciary obligations (§10)	Up to ₹150 crore
Breach of voluntary undertaking accepted by the Board (§32)	Up to the underlying penalty

One detail that often surprises finance teams: a single incident can trigger multiple penalty categories simultaneously. A data breach caused by inadequate security coupled with delayed notification could attract separate penalties under §8(5) and §8(6), each up to its own ceiling. The Board also has the power under Section 33(3) to double the penalty for repeat or grave breaches.

The cost of a ₹250 crore penalty dwarfs the cost of getting the SAP configuration right. There is no version of this where non-compliance is the cheaper option.

Who is personally liable

DPDPA penalty liability falls on the Data Fiduciary as an organization. But the accountability chain reaches further than that, and understanding it matters for how the programme gets resourced and governed.

The Board of Directors. For Significant Data Fiduciaries (SDFs), the Data Protection Officer reports directly to the Board of Directors. That reporting line is not ceremonial. It means the Board is on notice. An enforcement action against an SDF will ask what the Board knew, when they knew it, and what they did about it. Boards that have treated data protection as a technology problem delegated to IT are the ones that will find that answer uncomfortable.

The Data Protection Officer. SDFs must appoint an India-based DPO who serves as the primary point of contact for the Data Protection Board and for Data Principal grievances. The DPO does not personally bear penalty liability for the organisation’s breaches, but their decisions, recommendations, and documented concerns become part of the evidentiary record in any Board inquiry. A DPO who flagged an inadequate ILM configuration in writing, was overruled, and can demonstrate it, is in a different position from one who cannot.

The CISO and IT Security lead. Section 8(5) requires “reasonable security safeguards”. What counts as reasonable will be determined by the Board in the context of what was known, what was available, and what comparable organisations were doing. A CISO who can show a documented risk assessment, a RAL configuration, a deployed breach detection capability, and a tested incident response workflow is defensible. One who cannot is not.

Parallel proceedings under other laws. DPDPA penalties are without prejudice to any other action under any other law in force. A data breach involving employee records could attract concurrent action under the IT Act, 2000. A breach involving customer financial data could draw attention from the RBI or SEBI. Sectoral regulators in banking, insurance, and healthcare have their own data protection obligations that sit alongside DPDPA and are not displaced by it.

What the Data Protection Board can actually do

The Board’s enforcement powers are wider than the penalty schedule suggests. Understanding them is important for any organisation designing its response posture.

The Board can initiate a suo motu inquiry, without waiting for a Data Principal complaint, on the basis of media reports, whistleblower information, or a Central Government referral. It can demand documents, audit reports, and system logs. It can conduct hearings. It can issue binding directions requiring specific remedial action. And its decisions are published, which means an enforcement action is also a reputational event.

Appeals against Board decisions go to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT), and from there to the Supreme Court. The appeals process provides procedural protection, but it does not make an enforcement action cheap or fast. By the time an appeal is resolved, the reputational damage is done.

The Board can walk into your organisation’s SAP audit logs and ask to see them. If RAL is not configured, change documents are not active, and the IRT cannot produce a coherent response to a Data Principal request, the answer to “show us your compliance” is silence. Silence is not a defence.

The commercial exposure that predates enforcement

Regulatory penalties are the headline risk. They are not the only one.

Multinational companies operating in India are already asking their Indian vendors, outsourcing partners, and shared-services providers for DPDPA compliance attestations. The same pattern played out with GDPR in 2017 and 2018, where supply chain due diligence became a commercial prerequisite well before enforcement began. Organisations that cannot produce evidence of a functioning DPDPA compliance programme will lose contracts. Some already are.

For organisations that process employee data across borders, the cross-border data transfer provisions under DPDPA add a further dimension. The Central Government has yet to publish the whitelist of permitted jurisdictions. Until it does, every international HR data flow, every SuccessFactors instance hosted outside India, every Concur integration with a non-Indian data centre carries uncertainty. Organisations that have mapped their cross-border flows are better placed to respond when the whitelist arrives than those who have not.

A defensible implementation roadmap

For a mid-sized Indian SAP customer targeting the May 2027 enforcement deadline:

Figure 2: Implementation roadmap - five phases from inventory to go-live

Phase 1: Inventory and design (Q1–Q2 2026): Build the personal data inventory, document the Record of Processing Activities, map each Data Principal right to its SAP delivery, and design the cross-system orchestration. Pull Legal, Privacy, IT Security, and SAP functional teams into a single design forum. This phase is not glamorous and is the one most likely to be rushed. The quality of the design here determines everything downstream.
Phase 2: Foundation configuration (Q2–Q3 2026): Configure ILM retention, EoP checks, and blocking/deletion rules for customer, vendor, and employee data in S/4HANA. Configure SuccessFactors Data Retention Management. Configure RAL and activate change documents on all relevant master data objects. Expect this phase to overrun. It always does.
Phase 3: Rights workflow build (Q3–Q4 2026): Build the grievance management workflow (BTP, ServiceNow, or an existing service management platform). Build the IRT consolidation layer and cross-system Data Principal identification logic. Define response templates and timeline tracking. This phase determines whether the operational experience is smooth or painful.
Phase 4: Operational readiness (Q4 2026–Q1 2027): Train master data, HR, finance, and IT security teams. Run end-to-end test scenarios for each Data Principal right. Validate the breach notification workflow and consent withdrawal flows. Document the operational runbook in enough detail that someone unfamiliar with the system can follow it during an incident, because incidents rarely happen at convenient moments.
Phase 5: Go-live and continuous improvement (Q2 2027 onwards): Operate the framework in production. Review RAL logs and incident records on the cadence defined in Phase 1. Adjust ILM and EoP rules as Data Protection Board interpretation matures. Maintain the inventory, as SAP landscapes change continuously, and the inventory has to keep up.

A word on what DPDPA is not

DPDPA is not a copy of GDPR. Treating it as one is a category error that will cost the programme time and credibility. The Act has its own definitions, its own enforcement architecture under the Data Protection Board of India, and its own phased timeline. Some interpretive questions will remain open for two or three years as the Board issues guidance. Plan for that uncertainty rather than assuming the GDPR playbook translates directly.

The SAP-side implementation pattern is broadly familiar, because ILM, EoP, blocking and deletion, IRT, RAL, change documents, and the SuccessFactors data protection toolkit have all been refined through nearly a decade of GDPR-driven work. The capabilities exist. What is required now is to configure them for the Indian regulatory context, to orchestrate them across the systems where personal data actually lives, and to operate them consistently.

References

Disclaimer:
This article is for informational purposes only and does not constitute legal advice. Specific implementations should be scoped against the organisation’s processing activities, applicable sectoral regulations, the current text of the DPDP Rules, and prevailing guidance from the Data Protection Board of India.