Companies spend a lot of time evaluating vendors for security.
SOC 2 report. ISO certificate. Pen test. Security questionnaire.
Useful, but incomplete.
Privacy risk is about what the vendor does with personal data, for what purpose, where it goes, how long it remains, and what happens when you need it deleted.
If a SaaS provider processes your customer's email addresses, support conversations, or identity documents, you need a privacy view of that relationship as well.
Start with the role
First ask:
Is this vendor processing personal data on our behalf, or does it determine its own purposes?
Do not assume every vendor is a “processor.” Role depends on the actual processing arrangement.
Then capture:
- Purpose
- Data categories
- Data Principals
- Systems involved
- Countries
- Sub-processors
- Retention
- Deletion
The vendor assessment checklist
1. Data scope
What exact data does the vendor receive?
Avoid:
Customer data
Use:
Name, email, order ID, support message content
2. Purpose
What is the vendor doing with it?
If the contract says “services” and nobody can explain what that means, you have a problem.
3. Sub-processors
Ask who else receives the data.
A direct vendor relationship can hide multiple downstream entities.
4. Location
Know:
- Vendor entity
- Storage location
- Processing locations where material
- Cross-border movement
For DPDP, Section 16 matters; for GDPR, Chapter V may apply; sector-specific Indian rules may add restrictions.
5. Contract
For a processor relationship, verify the contract addresses the processing scope and relevant security, confidentiality, breach, sub-processing, and deletion obligations.
6. Deletion
The most useful question is:
“Show me how you delete one user's data.”
Then ask:
- API?
- Ticket?
- Automatic?
- Backup treatment?
- Sub-processor propagation?
- Evidence?
7. Breach notification
Your internal incident response is only as fast as the vendor information you receive.
Set an appropriate contractual notification expectation so you have time to assess and meet your own obligations.
8. Security assurance
Ask for:
- SOC 2 / ISO evidence where applicable
- Encryption information
- Access controls
- Incident response
- Audit reports
But do not treat a security certificate as proof of privacy compliance.
Tier the vendors
A simple risk model:
Tier 1: identity, financial, health, children's data, bulk personal data
Tier 2: ordinary personal data at material volume
Tier 3: limited or low-impact data
Then vary the review frequency and evidence depth.
Use the vendor assessment as an engineering input
If a vendor cannot delete data through an API, that affects your rights architecture.
If a vendor stores data outside India, that affects your transfer inventory.
If a vendor trains models on your content, that affects your purpose and contract analysis.
Vendor review should feed architecture decisions.
Common mistakes
SOC 2 = privacy. It is not.
Vendor's public policy = your contract. It is not.
No sub-processor review.
No deletion test.
Static vendor inventory.
Where Privra fits
Privra links vendor discovery to processing activities, data flows, contracts, deletion paths, and ongoing monitoring.
The goal is not to collect one more security questionnaire.
It is to know which vendors can touch which personal data and what happens next.