- Who controls the scan data, you or the vendor?
- What the contract has to add on top of the law
- Who owns the end-customer relationship?
- Can a vendor hold on to your scan data?
- What happens when the partnership ends?
- Four questions to put to any vendor before you sign
- Where the vendor’s model comes into it
- FAQ
Arun KrishnanSep 11, 20268 min read
You are about to put your name on an authentication platform you did not build. Every time a customer scans one of your products, that scan becomes a record: a real buyer, a real item, a time and a place. The question that decides the partnership is who controls that record, and the answer sits in two places, your data protection law and your contract.
In a white-label authentication partnership, the reseller whose brand sits on the product is normally the party that controls the scan data, while the vendor running the platform processes it on documented instructions and returns or deletes it when the agreement ends. India’s Digital Personal Data Protection Act, 2023 names you the Data Fiduciary and the vendor the Data Processor, and makes a written contract mandatory before the vendor processes a single scan. What settles it in practice is what the contract says, not who happens to store the data.
Who controls the scan data, you or the vendor?
The law answers this before the contract does. A Data Fiduciary is the party that determines the purpose and means of processing personal data, and a Data Processor is the party that processes it on the Fiduciary’s behalf (DPDP Act, 2023, section 2). You decide why the scans happen, so in the ordinary white-label arrangement you are the Fiduciary and the platform vendor is the Processor.
Under EU law the same split names you the controller and the vendor the processor (GDPR, Article 4). The UK regulator puts the consequence plainly: controllers "decide what personal data is collected and why, and exercise ultimate control over the data" (UK Information Commissioner’s Office, 19 November 2024).
Control follows the decision, not the server the scan lands on. A vendor hosting your data does not become its owner by hosting it.
What the contract has to add on top of the law
Data protection law settles who is accountable. It does not settle the commercial question of who may use the data, which is why the contract still decides the deal.
Guidance on SaaS agreements from the American Bar Association holds that a well-drafted agreement gives the customer ownership of its data and the intellectual property drawn from it (American Bar Association, Business Law Today, November 2021), leaving the provider the software and, at most, anonymised usage data (SolvLegal, 21 January 2026).
| Question | You, the reseller (Data Fiduciary, or controller) | The platform vendor (Data Processor) |
|---|---|---|
| Who decides why the data is collected? | You do. You set the purpose and the means. | Acts only on your documented instructions. |
| Who may use it for their own ends? | You may, within consent and the law. | May not. Doing so makes it a controller in its own right (GDPR Article 28(10)). |
| Who holds ultimate control? | You do, in the regulator’s own words (ICO, 19 November 2024). | None beyond what the contract grants. |
| What happens when the deal ends? | It returns to you or is destroyed at your choice. | Deletes or returns it and erases copies (GDPR Article 28(3)(g)). |
Who owns the end-customer relationship?
The relationship stays with the brand the customer sees, which in a white-label deal is yours (SolvLegal, 21 January 2026). The scan runs on your packaging and under your name, so the buyer it identifies is yours to keep engaging.
That matters more once loyalty sits on top of verification. A scan-to-earn program ties each scan and each redemption to a named consumer, so a purchase history forms under your brand rather than the vendor’s. Owning that history is the commercial half of owning the data.
Can a vendor hold on to your scan data?
Not if the arrangement follows the law. A processor may handle the data only on documented instructions (GDPR Article 28), and the moment it uses that data for its own purposes it becomes a controller, with the liability that follows (Article 28(10)).
The risk lives in the fine print, where a vendor reserves a quiet right to aggregate, analyse or sell the usage data your scans generate. The American Bar Association’s guidance is blunt on this: a provider should not be able to sell customer data to a third party even after it is cleansed of identifying information, and should be contractually barred from accessing or disclosing it.
An authentication scan is also not ordinary software telemetry. Generic telemetry records how people move through an app, so stripping identifiers costs the vendor little. An authentication scan ties a real buyer to a real item, which is a strategic asset rather than exhaust.
What happens when the partnership ends?
Under GDPR Article 28(3)(g), the processor must delete or return all personal data at your choice and delete its copies, unless a law forces it to keep them (GDPR Article 28; EDPB SME guide).
India’s DPDP Act is stricter on the same point. Once the purpose ends you must erase the data and cause your Data Processor to erase it (DPDP Act, 2023, section 8(7)). A guide for data fiduciaries from EY India reads the Act as mandating deletion where GDPR offers a delete-or-return choice, and notes that when a consumer withdraws consent, section 6(6) requires you and your vendor to stop processing within a reasonable time (EY India, 26 September 2025).
The carve-out is legal retention, where a statute compels a business to keep records for a set period. A well-drafted exit clause handles the rest by naming the export format for the returned data and requiring certified destruction of the copies.
Four questions to put to any vendor before you sign
Who owns the scan data and its analytics, in writing?
The contract should say that you own your customer data, the insights drawn from it, and the analytics on scans run under your brand, while the vendor holds the software and anonymised usage metadata. Treat an assurance that lives in a conversation rather than a clause as unsettled.
Can you get the data out on demand, and in what format?
A well-drafted agreement guarantees access during the term and a usable export format at exit. Fix the format in the contract, not in a support ticket two years later.
What happens to the data and its copies when the deal ends?
The vendor should delete or return everything at your choice and certify the copies are gone, unless a law requires retention. A clause permitting an indefinite backup is the one to renegotiate.
Does the vendor’s own business model reward keeping your data, or handing it back?
A platform whose product already delivers first-party data to the reseller has little reason to hoard it. One that monetises aggregated user data does. Judge the incentive alongside the clause.
Keep customer control inside your white-label offer
Evaluate Acviss authentication infrastructure for your reseller programme.
Where the vendor’s model comes into it
That last question is the one most buyers skip, and it is the most predictive. At Acviss we build our white-label authentication on the Processor side of that split, and we designed our loyalty product, Bonus, to push first-party data and sales insight back to the reseller on the label rather than pool it centrally. Certify provides the real-time scan analytics that go with it.
Hold any vendor to the written standard above, Acviss included, and let the contract rather than the pitch decide.
This article is general guidance on how these arrangements are usually structured. It is not legal advice, and your own counsel should review any agreement before you sign it.
FAQ
Does it matter where the vendor physically stores the scan data?
It matters for two reasons that have nothing to do with ownership. Cross-border transfer rules can restrict where personal data may go, and some brand customers write storage location into their own procurement requirements regardless of what the law demands. Ask the vendor which regions the data sits in, whether that can change without notice, and whether sub-processors abroad are involved. Then check it against the markets you sell into.
Who is liable if the vendor has a data breach?
Under the DPDP Act the compliance burden sits with the Data Fiduciary, so a breach at your processor is still your exposure to the regulator and to the affected individuals. The contract is where you recover from the vendor afterwards, through an indemnity, a liability cap you can live with, and a breach notification window measured in hours rather than days. Check the cap in particular, because a cap set at one year of fees may be smaller than the loss.
Do you need consent from the consumer who scans?
If the scan can identify a person, then generally yes, along with a notice that explains what you collect and why. An anonymous verification check that records nothing about the person is a different case from a loyalty scan tied to a phone number. The practical step is to separate the two flows at design time, so the verification works for everyone and the identified data only gets collected where a consumer has agreed to it.
Can you use scan data for your own marketing?
Only within the purpose the consumer was told about and consented to. Verification consent does not automatically extend to marketing, and stretching it is one of the more common ways a compliant program stops being compliant. If marketing is part of the plan, say so in the notice at the point of scan rather than inferring permission later.
What if your brand customer says the scan data is theirs, not yours?
This is the argument that actually arises, and it is a three-party problem the two-party contract does not solve. Your agreement with the platform vendor settles what sits between you and the vendor. It says nothing about what sits between you and the brand whose product carries the label. Decide that in the brand agreement: who is the Fiduciary for those scans, who may use the analytics, and what each side gets at exit. Leaving it unwritten means it gets decided during a dispute.
Build a white-label authentication programme with clear data control
Give customers branded verification, useful scan intelligence, and defined exit rights.
