A B2B SaaS company gets asked:
“Are you DPDP compliant?”
The founder says yes.
Then the enterprise customer asks:
“What data do you process on our behalf?”
The answer suddenly becomes complicated.
SaaS companies often operate in two roles at once.
For data about their own users, they may determine purposes and act as a Data Fiduciary.
For customer-provided end-user data, they may act as a Data Processor, depending on the arrangement.
The distinction is foundational.
Draw the two worlds separately
Your product users
→ your purposes
→ your processing
Customer's end users
→ customer's purposes
→ your processing on their instructions
These need different governance.
Your own users
Examples:
- Account creation
- Billing
- Product analytics
- Marketing
- Support
You need to understand the relevant legal basis, notice, rights, retention, and vendors.
Customer data
Examples:
- Customer uploads
- End-user profiles
- Tickets
- Transaction records
- Identity documents
The customer may determine the purpose.
Your contract and architecture should clearly define the relationship.
Why privacy policies confuse SaaS companies
A public privacy policy describes how the SaaS company handles personal data under its own role.
A customer DPA describes processing undertaken for customers.
Then there may be:
- Security documentation
- Subprocessor list
- Data residency documentation
- Trust Center
Do not use one document to pretend all relationships are identical.
The engineering implications
For customer data, the architecture should support:
- Tenant isolation
- Access controls
- Data exports
- Deletion paths
- Processor inventory
- Audit logs
- Configurable retention
For your own user data, you also need:
- Consent / preference architecture where relevant
- Product notices
- Marketing controls
- Rights workflows
The enterprise questionnaire problem
Large customers may ask:
- Where is customer data stored?
- Who are your subprocessors?
- Can you delete it?
- How long do backups remain?
- Do you use AI vendors?
- Do you use customer data for training?
A good privacy program should produce these answers continuously rather than scramble before every sales call.
Don't over-claim on certifications
SOC 2 can provide evidence about security controls.
ISO 27001 can provide evidence about an information security management system.
Neither automatically proves that your customer data processing complies with every applicable privacy law.
That distinction matters in enterprise sales.
Common mistakes
One privacy policy for every role.
DPA says one thing, product does another.
No tenant-level deletion.
Customer data copied into analytics without review.
AI feature added without checking whether customer content is being sent to a third party.
Where Privra fits
Privra can map both sides of the SaaS privacy model: your own processing and the customer data you process on behalf of others.
The objective is to make the role distinction visible all the way from contract to infrastructure.