GDPR, DPDP and Documentation: A Legal Overview for SaaS Teams

Why Documentation Is the Quiet Centerpiece of SaaS Compliance

Most engineering teams treat GDPR and India's Digital Personal Data Protection Act (DPDP) as a legal checkbox handed off to outside counsel. That posture fails for a simple reason: regulators in both jurisdictions have made documentation the primary evidence of compliance. A processor that cannot produce a current record of processing activities, a Data Protection Impact Assessment, or a lawful-basis register on demand is treated as non-compliant, regardless of how good the underlying controls happen to be.

This article is a practical overview for SaaS founders, engineering leads, and product managers who ship code that handles EU or Indian personal data. It is not a substitute for legal advice, but it will give you a working map of the documentation you are expected to maintain, how the two regimes differ, and how to make the work sustainable inside a small team.

The Two Regimes at a Glance

Dimension	GDPR (EU, 2018)	DPDP Act (India, 2023)
Effective date	May 25, 2018	Phased; key obligations from late 2023 onward
Extraterritorial reach	Yes, if you target EU data subjects	Yes, if you offer goods/services to individuals in India
Lawful bases	Six bases including consent, contract, legitimate interest	Primarily consent for digital personal data
Data fiduciary / controller equivalent	Controller and Processor	Data Fiduciary; significant distinction for "Significant Data Fiduciaries"
Data Protection Officer	Mandatory in specific cases (large-scale monitoring, special categories)	Mandatory for Significant Data Fiduciaries and on request
Cross-border transfer	Adequacy, SCCs, BCRs	Restricted to countries notified by the Indian government
Penalty ceiling	Up to 4% of global annual turnover or EUR 20M	Up to INR 250 crore per breach for failure to take reasonable safeguards

The two frameworks share a vocabulary but diverge on operational detail. A documentation strategy that satisfies one will not automatically satisfy the other, which is why dual-jurisdiction SaaS teams need a unified template that is parameterized by jurisdiction.

GDPR Documentation Duties: What Regulators Actually Ask For

The GDPR Article 30 record of processing activities (ROPA) is the single most-requested artifact in supervisory authority audits. It must contain, at minimum:

• Name and contact details of the controller, joint controllers, the controller's representative, and the DPO.
• Purposes of processing.
• A description of categories of data subjects and personal data.
• Categories of recipients to whom data has been or will be disclosed.
• Transfers of personal data to a third country and the documentation of suitable safeguards.
• Where possible, the envisaged time limits for erasure (retention).
• Where possible, a general description of the technical and organisational security measures.

A ROPA is a living document. Every new feature that processes personal data should trigger a delta to the ROPA, not an annual rewrite.

Beyond the ROPA, GDPR requires:

1. Data Protection Impact Assessments (DPIAs) under Article 35 for processing likely to result in a high risk to rights and freedoms. The Article 29 Working Party identified nine criteria; meeting two usually triggers a DPIA. Common SaaS triggers include systematic monitoring, large-scale profiling, processing children's data, and innovative uses of new technology.
2. Records of consent when consent is the lawful basis, including what the user was told, when they consented, and how they can withdraw it.
3. Article 28 processor contracts with every sub-processor in the chain. Self-hosted tools and open-source libraries are not processors; managed SaaS vendors you route personal data through almost certainly are.
4. Breach documentation under Article 33, including the 72-hour notification timeline.
5. Data subject request handling with a defined process for access, rectification, erasure, portability, restriction, and objection.

A practical artifact often overlooked is the Lawful Basis Register, which maps each processing activity in the ROPA to one of the six lawful bases and records the justification. Auditors consistently flag organizations that can produce a ROPA but cannot explain why each row uses the basis it does.

Sample ROPA Row

Processing activity: Account creation and authentication
Purpose: Provide access to the product
Categories of data subjects: Authenticated users (customers, end users)
Categories of personal data: Email, hashed password, IP, user agent
Lawful basis: Contract (Art. 6(1)(b))
Retention: Account lifetime + 30 days soft delete; logs 90 days
Recipients: Auth provider (Auth0), email provider (Postmark), error tracking (Sentry)
Transfers: United States - EU-US Data Privacy Framework
Security measures: TLS 1.2+, Argon2id hashing, MFA optional

That single row touches every Article 30 element and is auditable on its own. Multiply it by the number of features in a SaaS product and you have a real ROPA.

DPDP Act: The New Indian Reality

India's DPDP Act took a different design path. It is a consent-centric, fiduciary-driven model with a smaller set of explicit obligations and a heavier reliance on penalties. The central government has notified the Data Protection Board, and implementation rules have been released in phases through 2024 and 2025.

Key Concepts

• Data Principal: the individual whose data is processed. Equivalent to a data subject.
• Data Fiduciary: the entity that determines the purpose and means of processing. Equivalent to a controller.
• Data Processor: processes data on behalf of the fiduciary, with no decision-making role.
• Significant Data Fiduciary: a class notified by the central government based on volume, sensitivity, and risk. They have additional obligations including DPO appointment, audit, and DPIA.
• Personal Data: any data about an individual.
• Consent: free, specific, informed, unconditional, unambiguous, with a clear affirmative action. Withdrawal must be as easy as giving consent.

Documentation Duties Under DPDP

The Act's text and accompanying rules push fiduciary obligations into three documentation layers:

1. Notice and consent records: a clear notice at the time of consent, in English or any of the 22 scheduled languages, describing the personal data being collected, the purpose, and the manner of exercise of rights.
2. Security safeguards: reasonable security safeguards to prevent personal data breach, as specified in rules. The Rules detail encryption, access controls, logging, and breach response.
3. Breach notification: notify the Board and affected Data Principals in the event of a personal data breach, with prescribed timelines and content.

The Act does not require a ROPA by name, but the combination of notice records, security safeguards, and breach documentation is functionally similar. A practical approach is to maintain a single ROPA template that can be exported as a DPDP-format notice and consent artifact when needed.

Cross-Border Transfers

Section 16 of DPDP restricts transfer of personal data outside India to countries or territories notified by the central government. The notified list is the counterpart to an adequacy decision under GDPR. If your SaaS uses AWS, GCP, or Azure regions outside India for Indian end users, this is a live concern, not a hypothetical one. Track the notified list at minimum quarterly.

Children's Data

DPDP Article 9 prohibits processing personal data of children under 18 without verifiable parental consent. This is stricter than GDPR's default of 16 (member states can lower to 13) and creates a documentation requirement: proof of the parental consent mechanism.

Where GDPR and DPDP Diverge in Practice

Question	GDPR answer	DPDP answer
What is the lawful basis for analytics on logged-in users?	Often legitimate interest with a balancing test	Almost always requires consent; legitimate interest is not enumerated
Can we rely on contractual necessity for B2B processing?	Yes, Art. 6(1)(b) is broad	Yes, but the contract must be specifically named and limited
Can we send marketing to existing customers?	Soft opt-in under ePrivacy, with safeguards	Requires fresh consent; no implied consent from a transaction
Is there a DPIA trigger for a new AI feature?	Almost always, if it profiles or monitors	Likely yes if it processes children or large volumes
Do we need a DPO?	Depends on scale and special categories	Yes, if you are notified as a Significant Data Fiduciary

The operational cost of dual compliance is mostly in the lawful basis mapping. Engineers tend to assume "legitimate interest" because it feels flexible; under DPDP, it does not exist as a free-standing ground for most processing. Capture the legal basis at the schema level, not in a wiki page.

Documentation Architecture: Where the Code Meets the Law

A documentation architecture that survives an audit has three layers, each with a different owner and refresh cadence.

Layer 1: Code-Generated Inventory

Every endpoint, worker, and background job that touches personal data should be discoverable. The cheapest way to get there is to put a single line of metadata next to the data access. A decorator-based approach in Python, a tag system in Go, or a structured // @pii comment in TypeScript can be parsed by CI to produce a raw inventory. The inventory is not a legal document; it is the source of truth that legal review transforms into a ROPA.

@processes_pii(fields=["email", "ip"], purpose="authentication", basis="contract")
def login_view(request):
    ...

The win is that when you add a feature, the inventory updates without anyone remembering to update a spreadsheet.

Layer 2: The ROPA Template

A ROPA template lives in a docs repo (often Markdown or a structured YAML), one row per processing activity. Each row references the code-generated inventory, and each change to the row is reviewed by whoever owns the data function for the product. Pull request review is the audit trail.

Layer 3: The Public-Facing Notice

The privacy notice, cookie policy, and DPA template are derived from the ROPA and refreshed when the ROPA changes. This is where most teams get the order backwards: they write the privacy notice first and try to reverse-engineer the ROPA to match it. The ROPA is the system of record.

A 90-Day Plan for Getting Audit-Ready

If you have none of this in place today, here is a realistic 90-day sequence for a small SaaS team.

Weeks 1 to 2: Inventory. Instrument code to produce a PII inventory. Identify the top twenty processing activities by volume and risk. Interview two or three engineers per product area to fill gaps the code search misses.

Weeks 3 to 6: ROPA and lawful basis map. Produce the first version of the ROPA with each row reviewed by a product or engineering owner. Resolve the most ambiguous lawful bases with outside counsel. Do not aim for perfection; aim for a defensible first draft.

Weeks 7 to 9: Contracts and sub-processors. Audit every vendor that receives personal data. Verify Article 28 terms and DPDP-compliant data processing agreements. Add a sub-processor list to your trust page.

Weeks 10 to 12: Breach response and rights requests. Document the breach response runbook end-to-end, including who decides whether notification is required, who drafts the notice, and who contacts the supervisory authority or the Data Protection Board. Build a rights-request intake, ideally through the same support system you already use.

At the end of the 90 days, you should be able to answer four questions within an hour: what personal data do we process, why, on what legal basis, and where does it go. Most teams that cannot answer those four questions are operating outside the safe harbor of either GDPR or DPDP, regardless of what their privacy policy says.

Common Mistakes That Cost Real Money

• Treating the privacy notice as the compliance artifact. The notice is a derivative document. Auditors want the ROPA, not the polished PDF.
• Letting vendors drift. Every new analytics SDK, error tracker, or AI assistant that ingests user data is a new processing relationship. Vendors drift faster than any other part of the stack.
• Ignoring logs. Application logs routinely capture personal data. They need their own retention, redaction, and lawful basis.
• Skipping DPIAs because the feature feels small. The volume threshold is large-scale, but the qualitative triggers include profiling and tracking, which cover most B2B SaaS products.
• One language for both regimes. A cookie banner that satisfies GDPR ePrivacy will not satisfy DPDP consent if it bundles purposes or makes withdrawal harder than acceptance.

How DocPilot Helps Keep This Documentation Honest

Documentation rot is the silent killer of GDPR and DPDP compliance. A ROPA written eighteen months ago is fiction the moment a new feature ships. The hard part is not the writing; it is keeping the artifact in sync with the codebase, the sub-processor list, and the public notice.

DocPilot connects to your GitHub repository and generates living documentation directly from the code, including architecture, API references, and setup guides. For compliance-adjacent documentation such as processing inventories, ROPA drafts, and sub-processor lists, the same source-of-truth principle applies: write the artifact once, derive it from code, and let webhooks refresh it on every merge. Teams that adopt this pattern spend a fraction of the time on audit prep that teams relying on shared drives do, and they pass audits that the others fail.

If you are starting the 90-day plan above, begin with the inventory, then put the rest in a repo that DocPilot can watch. By the end of the first quarter, your compliance documentation will be as current as your main branch.

Disclaimer: This article is a practical overview and does not constitute legal advice. Engage counsel licensed in the relevant jurisdictions for advice on your specific processing activities.