DPDP Checklist for SaaS: Duties, Evidence and Release Tests
Build a SaaS DPDP work plan from applicable duties, staged commencement, processing maps, consent, rights, incident response, and verified evidence.
Build a DPDP work plan from your processing activities and the provisions that apply to them. Assign an owner and evidence to each task. Separate legal applicability from the software controls that support it.
The notified Rules use staged commencement. Rule 4 has a different schedule from the main application-facing duties. Check the Act's commencement notifications separately. A single headline deadline is not a complete implementation plan.
Record the applicable commencement group
| Rule group | Schedule under Rule 1 |
|---|---|
| Rules 1, 2 and 17–21 | Gazette publication |
| Rule 4 | One year after publication |
| Rules 3, 5–16, 22 and 23 | Eighteen months after publication |
Read the actual notification and check for later amendments. Do not treat the date printed on a notification as proof of its publication date. Notified DPDP Rules.
The commencement and engineering guide explains the groups. Your applicability review must also address the Act and any relevant sector requirements.
Map the processing and responsible actors
Identify who decides the purpose and means of each activity. Identify processors and other recipients. One organization can have different roles for different activities.
Use the Data Fiduciary and Data Processor guide to structure that review. Keep the final applicability decision with the responsible organizational owner.
| Record | Useful content |
|---|---|
| Activity | Account creation, support, billing or another specific purpose |
| Data | Actual fields and record categories |
| Actor | Responsible organization and contracted processor |
| Recipient | Provider, subprocessor or internal team |
| System | Database, log, queue, export or backup |
| Retention | Rule, reason and cleanup owner |
| Evidence | Configuration, contract or observed test |
A diagram that omits logs and support exports can miss important processing boundaries.
Build notice and consent evidence
Map the notice to the data and purpose actually presented to the person. Record the applicable processing basis. Where consent is the basis, preserve the choice and the notice version.
An OAuth scope is a permission in a particular protocol. A DigiLocker document grant serves its requester workflow. Neither alone establishes the complete privacy notice and consent process. Consent mechanism boundaries.
For an engineering exercise, test the same choice across web and mobile. Confirm that withdrawal reaches the systems that depend on it. Record any processing that continues under a separately reviewed basis.
Use the startup privacy notice guide to connect the text to the processing map.
Route rights requests through every relevant system
Create a controlled request intake and an identity-checking process. Route the request to the responsible owner. Track the actual data locations and any applicable retention requirement.
Do not label soft deletion as complete erasure. A deleted account can still have personal data in connected systems. Keep a reason and owner for retained records.
Use the rights-request engineering guide for implementation planning. Review the applicable deadlines rather than applying a grievance-response period to every request.
Rehearse security and incident workflows
Rule 7 is in the eighteen-month commencement group. Under that rule, initial Board and affected-person notices are without delay. The detailed Board report has a separate 72-hour period, subject to the rule's extension mechanism. Verify applicability before applying this schedule to an actual incident. Rule 7 workflow and exercise.
Prepare the owners, timestamps, decision record and communication drafts before an exercise. Treat other incident-reporting duties as separate requirements.
Test account revocation and resource access together. An identity-provider logout may leave an application session or issued access token usable. Logout and revocation boundaries.
Verify processors and retention controls
Review contracts, processing locations, subprocessors and incident escalation. Match each promise to the actual service configuration. Ask for evidence of deletion and recovery behavior where relevant.
A hosting region does not describe every connected provider. Authentication logs also do not establish what business record a user opened. Use the retention guide and audit guide to identify missing evidence.
Turn the review into a release checklist
- Record the applicable provision and commencement basis.
- Assign a responsible owner for each processing activity.
- Map fields, recipients, systems and retention.
- Match notices to actual processing.
- Test consent and withdrawal where applicable.
- Test rights-request routing and completion evidence.
- Rehearse revocation and incident escalation.
- Review processor contracts and configuration.
- Record unresolved risks and the next review date.
Use the DPDP and GDPR engineering comparison when both frameworks are relevant. This checklist supports planning; it does not establish legal conformity.
Review identity controls with NamoID
NamoID engineers can help review sign-in, sessions and available identity-layer evidence. Your organization owns the broader privacy process and applicability decisions.
Share your stack and one synthetic request journey in Slack for an early response. Contact the NamoID team