UI UX Design Services, security and the DPDP Act: a compliance checklist
Is UI UX design services compliant with the DPDP Act?
UI UX design services are not compliant or non-compliant in themselves. India's DPDP Act regulates how your product collects, shows and deletes personal data, and design decides most of that: consent screens, form fields, default toggles and access requests.
UI UX design services are not certified compliant or non-compliant in themselves. India's Digital Personal Data Protection Act 2023 regulates how your product collects, shows and deletes personal data, and design decides most of that: consent screens, form fields, default toggles, retention notices and access requests. Compliant design is a set of artefacts, not a badge a studio can wave.
This checklist maps each DPDP obligation that touches an interface onto the design artefact that satisfies it, covers the security of the design process itself (where research recordings live, who can open the prototype), and is honest about the cases where a full compliance programme around a design engagement is wasted effort.
What the DPDP Act asks of an interface
The DPDP Act 2023 places duties on the data fiduciary, which is your company, not your design vendor. The Ministry of Electronics and Information Technology publishes the Act and the subsequent rules on its data protection framework pages. Four of its duties land almost entirely in the interface: give notice before or at the time of collection, obtain consent that is free, specific and informed, let the person withdraw consent as easily as they gave it, and honour requests for access, correction and erasure.
Read those four as design requirements and they become concrete. Notice means a screen, in the user's language, that says what you are collecting and why, in plain words rather than a link to a twelve-page policy. Specific consent means separate toggles for separate purposes rather than one blanket acceptance. As easy to withdraw means the off switch is no more than one level deeper than the on switch. Access and erasure mean a real screen in account settings, not an email address that reaches a shared inbox.
The Act also recognises children's data as a special category with verifiable parental consent and a prohibition on tracking or behavioural advertising directed at children. If your product has any chance of under-18 users, that constraint shapes signup, analytics and notification design from the first wireframe. Our post on learner data protection works through the education case in detail.
Obligation to artefact: the mapping
Use this table as the review sheet for design handover. Each row is a DPDP duty, the thing the design has to show, and the person who signs it off.
| DPDP duty | What the design must show | Artefact at handover | Sign-off |
|---|---|---|---|
| Notice at collection | Plain-language purpose beside each data request | Annotated signup and form screens | Legal and product |
| Free, specific consent | Separate, unticked toggles per purpose | Consent screen with default states marked | Legal |
| Easy withdrawal | Off switch at the same depth as the on switch | Settings information architecture map | Product |
| Access and correction | A self-service screen listing stored fields | Account data screen and edit states | Product and engineering |
| Erasure | A delete-account path with consequence copy | Deletion flow including the confirmation step | Legal and engineering |
| Children's data | Age gate and parental consent path | Age assurance flow, tracking excluded | Legal |
| Breach notification | In-product notice pattern held ready | Notification template and placement | Security |
The column that gets skipped is the last one. An artefact nobody signed is a suggestion. We put named sign-off against each row before the design is handed to engineering, because retro-fitting a consent model after build is the expensive version of this work.
The consent patterns designers get wrong
Most DPDP problems in an interface come from six recurring patterns, all of which look like good conversion design and all of which fail the free and specific test.
- Pre-ticked boxes. Consent must be an affirmative action. A default-on marketing toggle is not consent, however clearly it is labelled.
- Bundled purposes. One tick covering service delivery, marketing and analytics fails specificity. Split them, even though the marketing opt-in rate will fall.
- Asymmetric buttons. A bright Accept All next to a grey text link labelled Manage is a dark pattern, and regulators read it as one.
- Consent buried in terms. Acceptance of terms of service is not consent to process personal data for a separate purpose.
- Hidden withdrawal. If enabling location took one tap and disabling it takes four screens, the design fails the equally-easy test.
- English-only notice. The Act requires notice to be available in the languages listed in the Eighth Schedule of the Constitution. Plan the layout for longer Devanagari and Tamil strings.
Accessibility belongs in the same review. A consent screen a screen-reader user cannot operate is not informed consent, so hold the flow to WCAG 2.2 level AA on focus order, target size and error identification at the same audit.
Security of the design process itself
The second half of UI UX design services security has nothing to do with the product and everything to do with the studio. Design work generates personal data of its own, and it is usually the least governed data in the programme.
Research recordings and transcripts
User interviews capture faces, voices, names and sometimes live screens containing customer records. Treat them as personal data: a signed research consent form per participant, storage in your tenancy rather than the vendor's personal cloud drive, a stated retention period of ninety days unless the participant agrees otherwise, and blurring or redaction of any account data visible on a shared screen. The PII redaction entry describes the technique we apply to screen recordings.
Prototypes and seeded data
The fastest way to leak production data in a design engagement is a clickable prototype seeded with a real customer export so it demos well. Seed prototypes with generated data instead. If a realistic dataset is genuinely required for a usability test, use a masked extract and keep it inside your environment. Prototype sharing links should expire and be access-listed rather than public-by-URL.
Access, offboarding and residency
Designers need named accounts in your tooling, removed on the day they roll off, with an audit trail of who opened what. Where the client requires Indian data residency, the design tooling counts: research recordings and analytics exports stored in a region you have not approved are as much of a problem as an application database in the wrong place. Agree the tool list and the regions in the contract, not in week six.
What compliant design work costs
Compliance work is scope, not a surcharge. Eazyware's UI/UX design and development engagements run from $5,500 or ₹3,60,000 to $28,000 or ₹18,40,000, and a DPDP-shaped consent, settings and deletion set adds flows rather than a separate line item: typically the consent screen, the account data screen, the deletion flow and an age gate. Published starting prices for every service sit on the pricing page. For Indian clients we invoice in INR with GST, and we sign an NDA before the first working session.
Ongoing cost is the audit cycle. A Care Plan from $1,000 or ₹68,000 a month covers re-auditing the consent and settings flows after each release, because a new feature that quietly adds a data purpose is the most common way a compliant product stops being one.
When this checklist is more than you need
If your product handles no personal data beyond a work email address for login, most of this is ceremony. Write the notice, make deletion real, and move on. A full artefact set with legal sign-off per row is proportionate when you process financial, health, location or children's data, or when an enterprise buyer's security review will inspect it.
It is also the wrong order of work if the product does not exist yet. Design the core experience first and apply the consent model once the data map is stable, otherwise you will redraw the consent screens three times. The exception is an age gate: if children are in scope, that decision sits at the front, because it changes signup, analytics and notifications.
A worked example
Onboarding at a regulated lender is the hardest version of this problem. In the KYC and loan onboarding work we did for an NBFC, the documents involved are identity documents, so every screen that displays or uploads one carries a notice, a purpose and a retention consequence, and the processing stayed inside the client's own environment. The design question is not whether to show a consent screen but how to make a heavily regulated flow finishable on a mid-range Android phone with a weak connection. Those two goals pull against each other, and the resolution is progressive disclosure with the notice attached to each field rather than one wall of text at the start.
Checklist before design handover
- Every form field mapped to a stated purpose and a retention period
- Consent toggles separated by purpose, all defaulting to off
- Withdrawal path no deeper than the path that granted consent
- Self-service access, correction and deletion screens designed, not promised
- Age gate decided, with tracking excluded for minors if in scope
- Notice copy available in the languages your users actually read
- Consent and settings flows audited against WCAG 2.2 level AA
- Research recordings, prototypes and exports stored in an approved region with named access
Related reading
DPDP Act 2023 and AI: what Indian companies must do covers the obligations beyond the interface, SSO, RBAC and audit logs explains the access controls the settings screens depend on, and UI UX design services in India sets out delivery models and data rules for Indian engagements. The DPDP Act 2023 glossary entry is the short definition.
Compliance in design is not a page of legal copy; it is defaults, depth of navigation and the deletion button you were hoping nobody would ask for.
Frequently asked questions
Does the DPDP Act apply to a design agency or to the client?
▾
It applies to the data fiduciary, which is the company that decides why and how personal data is processed, so usually the client. A design vendor acts as a processor for research data it holds. Both positions need contractual terms covering purpose, retention, residency and deletion.
Are pre-ticked consent boxes allowed under the DPDP Act?
▾
No. Consent must be a free, specific, informed and unambiguous affirmative action, so toggles must default to off and each purpose needs its own control. Bundling marketing and analytics consent into acceptance of terms of service does not meet the standard and is the most common design failure we see.
How should user research recordings be handled?
▾
Treat them as personal data. Take written participant consent, store recordings in the client's tenancy in an approved region, set a retention period of around ninety days, redact any customer records visible on shared screens, and remove designer access on the day they leave the engagement.