Your company signs contracts with dozens of SaaS providers.
Some send email. Some host databases. Some analyse behaviour. Some provide customer support. Some process KYC documents. Some send data to AI models.
The Data Processing Agreement is the part of that relationship that defines the privacy boundaries.
Under GDPR, Article 28 sets out detailed processor-contract requirements. Under DPDP, Section 8(2) requires a valid contract where a Data Fiduciary engages a Data Processor to process personal data on its behalf.
The legal text is only half the problem.
The other half is whether the contract matches production.
What the DPA should make clear
1. Subject matter and duration
What processing is the vendor actually performing?
For how long?
2. Nature and purpose
Do not write:
To provide services.
Write:
Transactional email delivery for account notifications and password-reset messages.
Precision creates control.
3. Data categories
Name them.
Example:
- Phone
- User ID
- Order ID
Do not write “all customer information” unless the contract truly intends to permit that breadth.
4. Data Principal / data subject categories
Describe who the people are:
- Customers
- Employees
- Applicants
- End users
5. Processor instructions
The processor should process according to documented instructions and agreed purposes.
6. Confidentiality
People with access should be bound by appropriate confidentiality duties.
7. Security
Reference concrete controls rather than only saying “industry-standard security.”
8. Sub-processors
Define how they are added, what notice is provided, and what control the customer has.
9. Assistance
For applicable regimes and contracts, the processor may need to assist with rights requests, security incidents, assessments, and other obligations.
10. Deletion and return
Define what happens when:
- The contract ends
- Processing is no longer needed
- A rights request applies
Also clarify backup treatment where relevant.
11. Breach notification
The DPA should provide enough time for your company to assess and act. A vendor notification arriving at the end of your own regulatory deadline is operationally useless.
Compare the DPA with the system
This step is often skipped.
Contract:
Data is processed only to provide support.
Production:
Support messages are copied to a separate AI provider for summarisation.
That is a governance gap.
The system might be the source of truth for what happens, but the contract determines what you have agreed to.
You need both to match.
When vendors refuse your DPA
This happens.
A smaller startup may accept the vendor's terms.
A larger buyer may negotiate.
The important thing is risk visibility.
Document:
- What you asked for
- What the vendor accepted
- What they refused
- Residual risk
- Compensating controls
- Whether you will replace them later
Common mistakes
Signing one generic DPA for everything.
No sub-processor visibility.
No deletion mechanics.
72-hour breach language copied without operational thought.
Contract not updated when the service changes.
Where Privra fits
Privra can map the contract view to the infrastructure view: what vendors are supposed to receive, what they actually receive, and whether the deletion, consent, and monitoring workflows reach them.
A DPA is useful when it constrains something that can actually happen.