The short version
- On your work, you are the Data Fiduciary and we are your Data Processor. We act on your instructions, nothing more.
- We sign a data processing agreement before we touch anything, and we bring the draft.
- Named logins only. No shared accounts, no credentials over email or chat, access revoked the day someone leaves.
- We will not upload a customer list to an ad platform until you confirm in writing that you have a lawful basis for it.
- We publish our subprocessors, and we tell you before we add one.
1. Who is responsible for what
The Act divides everyone into two roles, and the division decides who carries the liability. It is worth being precise about it, because a vague answer here is the first sign an agency has not done the work.
| Context | You | Us |
|---|---|---|
| Your customers' data, in your CRM, site, ad accounts and analytics | Data Fiduciary — you decide why and how | Data Processor — we act on your documented instructions |
| Enquiries you send us, and your team's contact details | Data Principal | Data Fiduciary |
| Advertising platforms you ask us to run | Data Fiduciary | We configure; the platform processes under your platform terms |
Because Section 8(5) makes you responsible for the security of data processed on your behalf, our job is to make that responsibility easy for you to discharge and easy to evidence. Every control below exists for that reason.
2. Before we touch your data
Four things happen before anyone on our team opens one of your platforms.
- A data processing agreement is signed. We bring the draft. It names the processing activities, the categories of data, the subprocessors, the security measures, the retention position and what happens at the end. If you have your own paper, we will work to it.
- Scope is written down. Which systems, which data, which people. Anything outside that list is a change request, not an assumption.
- Access is granted natively and individually. Each person gets their own account on your platform, with multi-factor authentication. We will decline a shared login even when it is offered, because it destroys your audit trail as well as ours.
- The lawful basis is confirmed for anything we will share onward. Covered in §4.
3. The controls we run
Rule 6 of the DPDP Rules names what reasonable security safeguards look like. This is our implementation of it.
| Safeguard | How we run it |
|---|---|
| Encryption | TLS in transit everywhere. At rest wherever the platform supports it. No client data on personal devices without disk encryption |
| Masking and obfuscation | Session recording and heatmap tools configured with input masking on by default. Customer-level exports reduced to the fields the analysis actually needs |
| Access control | Named accounts, multi-factor authentication, least privilege. Nobody holds standing access to a system their current work does not require |
| Access logs | Platform-native logging left on and not cleared. Our own access grants and revocations recorded with dates |
| Revocation | Runs on two triggers — a person leaves the team, or an engagement ends. Completed within 2 business days and confirmed to you in writing |
| Credential handling | Platform-native access grants, or a password manager. Never email, chat, WhatsApp or a shared document |
| Retention on our side | Exports, raw files and screenshots deleted on a schedule and at the end of the engagement, with the deletion recorded |
| Confidentiality | Written obligations on everyone who works with us, employees and contractors alike |
4. The marketing-specific risks
This is the section that matters, and it is the one most agencies skip. Running paid media moves personal data in ways that are easy to miss, because the platforms make them one click deep.
Hashing is not anonymisation
A hashed email address in a Customer Match or Custom Audience upload is pseudonymised, not anonymous. It is still personal data, and sharing it with an advertising platform is still processing that needs a basis. Any agency that tells you hashing removes the obligation has told you something convenient rather than something true.
| Activity | Our rule |
|---|---|
| Customer Match, Custom Audiences, lookalike seeds | No list goes to a platform until you confirm in writing that you have a lawful basis for sharing it. One email is enough. We keep that confirmation with the campaign record |
| Conversions API and server-side tagging | Consent state is passed through to the server container. If a visitor refused advertising cookies, the server-side event does not fire for them either. This is the most commonly missed control in the entire stack |
| Offline conversion imports | Treated exactly like an audience upload — same written confirmation, same record |
| Pixels on checkout and confirmation pages | Blocked until consent, like every other non-essential tag. Order value and identifiers are never sent ahead of it |
| Session recording and heatmaps | Input masking on before the first recording, not after. Recordings start only after consent, and are excluded from pages where sensitive fields appear |
| Reporting and exports | Aggregated by default. Customer-level data only where the analysis genuinely requires it, held for a stated period, then deleted |
| Audience and list expiry | Seeds and uploaded lists are refreshed and re-confirmed rather than left running indefinitely on a basis that may no longer hold |
5. What we will not do
Stated plainly, because a list of commitments is only meaningful alongside the things we decline.
- Use a shared login, however convenient, and however often it is offered.
- Accept credentials over email, chat or WhatsApp.
- Upload a customer list to any platform without your written confirmation of a lawful basis.
- Install a tracker that fires before consent, or sign off a consent banner that asks after the tags have already loaded.
- Use one client's data to benefit another, in any form, including as a seed, a benchmark or a lookalike.
- Keep your data after an engagement ends, beyond anything a law requires us to retain.
- Tell you that hashing, aggregation or a US-headquartered platform removes an obligation that the Act places on you.
6. Subprocessors
We use third-party services to do the work. Which ones depends on your stack, and the list is agreed in the data processing agreement rather than assumed. The usual categories:
- Advertising platforms — Google, Meta, LinkedIn, Microsoft, and any others you run
- Analytics and measurement — including server-side tagging infrastructure where we build it
- Experimentation and session analysis — testing and behaviour tools
- Collaboration and storage — where briefs, reports and credentials live
We tell you before we add a subprocessor that will handle your data, and you can object. A current named list for your engagement is available on request at any time.
7. If something goes wrong
You carry the notification obligation under the Act. We make it possible for you to meet it, which means our clock has to be faster than yours.
| Step | When |
|---|---|
| We tell you | Without delay, and in any event within 24 hours of becoming aware |
| First assessment | What happened, what data, how many people, what we have already contained |
| Full support pack | Within 48 hours — the detail you need for your own report to the Data Protection Board, which is due within 72 hours |
| Remediation | Containment first, then cause, then the change that stops it recurring, reported to you in writing |
Our 24-hour and 48-hour commitments exist so your own 72-hour obligation to the Board is comfortable rather than tight. We would rather tell you about something that turns out to be nothing.
8. Requests from your customers
If one of your customers asks for access, correction or erasure, that request belongs to you — you are the Data Fiduciary and the decision is yours. What we do:
- Act on your instruction, within 7 business days of receiving it, so you can meet your own timeline comfortably
- Carry erasure through to every system we hold data in on your behalf, including exports and working files, and confirm it in writing
- Tell you where a platform's own retention limits what we can delete, rather than implying a deletion is complete when it is not
- Forward any request that reaches us directly to you, and never answer it ourselves
Under Rules 13 and 14 you have up to 90 days for grievances and erasure requests. Our turnaround is set to leave you most of that window.
9. What we need from you
Compliance here is genuinely shared, and three things from your side make the difference.
- A consent mechanism that actually blocks. If your banner fires tags before consent, nothing we do downstream can fix the basis. If it does not block today, we will tell you, and fixing it is work we can do.
- A clear answer on lawful basis for any list you want used. You do not need a legal memo. You need to be able to say how those customers were collected and what they were told.
- Notice of changes to your own privacy notice or stack. If you add a tool that collects personal data, or change what your notice says, the processing we run on your behalf may need to change with it.
10. Where we are
The Act's substantive obligations commence on 13 May 2027. We would rather show you our position than claim a finished one.
| Item | Status | Target |
|---|---|---|
| Privacy notice meeting the Rule 3 content requirements | Live | Done |
| Named grievance contact published | Live — Abhishek Mago, Founder & CEO | Done |
| Access control, named logins, revocation process | Operating | Done |
| Rules on audience uploads and server-side consent state | Operating | Done |
| Our standard data processing agreement | In drafting, with counsel review to follow | December 2026 |
| Consent banner with genuine tag-blocking on this site | In build | December 2026 |
| Full data map and documented retention schedule | Planned | June 2027 |
We are not a Significant Data Fiduciary and have not been designated as one, so the additional obligations under Section 10 — an India-based Data Protection Officer, an independent data auditor, annual impact assessments and algorithmic due diligence — do not currently apply to us. If that ever changes, this page will say so.
11. Contact
Data protection enquiries
- enquiry@arprconsulting.com
- Grievance Officer
- Abhishek Mago, Founder & CEO
- Phone
- +91 98734 42222
- Acknowledgement
- Within 2 business days
If you are running a vendor assessment and need this in your own questionnaire format, send it over. We answer them rather than asking you to accept a page.
This page describes our practices. It is not legal advice, and it does not replace the data processing agreement for your engagement — where the two differ, that agreement governs. See also our Privacy policy, Terms and conditions and Accessibility statement.