Enterprise B2B SaaS motions typically require a DPA before contract signing. Vendors with a standard DPA available on request move through procurement faster than vendors who have to draft one each time.
A DPA (Data Processing Agreement) is a contract between a controller (the customer who owns the personal data) and a processor (the vendor processing the data on the customer's behalf) that defines how personal data is handled. Required under GDPR Article 28 for any vendor processing EU personal data, and standard practice for processing personal data under CCPA and other privacy regulations. DPAs cover processing scope, security measures, sub-processor rules, breach notification, and data return or deletion.
The five things to understand about DPAs before signing one with a vendor or requesting one from a buyer.
A DPA is a contract between a data controller (the customer whose personal data is being processed) and a data processor (the vendor processing the data). The DPA defines the processor's obligations in handling the controller's personal data. Required under GDPR Article 28 and standard practice under CCPA, LGPD, and other privacy regulations.
A DPA is required when a vendor processes personal data on behalf of a customer. For B2B SaaS, this is most vendors: CRM systems process contact data, marketing platforms process consumer data, support tools process customer tickets. If the vendor touches personal data belonging to the customer's users or customers, a DPA applies.
A DPA covers specific areas: scope of processing, security measures, use of sub-processors, international data transfers, breach notification timelines, audit rights, and data return or deletion at contract end. Standard DPAs follow a conventional structure that enterprise procurement teams expect.
When a vendor processes EU personal data outside the EU (US-based SaaS, for example), the DPA usually includes Standard Contractual Clauses (SCCs) approved by the European Commission. SCCs provide the legal mechanism for international data transfers. Vendors without SCC-ready DPAs lose EU buyers during procurement.
Mature SaaS vendors maintain a standard DPA that buyers can request during procurement. The DPA typically gets attached to the master services agreement at contract signing. Vendors who have to draft a custom DPA for each deal add weeks to the sales cycle. Standard DPAs are a procurement velocity feature.
A standard DPA follows a conventional structure. The six sections below are the ones that recur across enterprise B2B SaaS DPAs. Each section serves a specific compliance purpose.
The scope section defines what personal data is being processed, for what purposes, and under what instructions from the controller. The processor cannot process data outside the stated scope. Common scope elements include types of data subjects (customers, employees), data categories (contact information, usage data), and processing purposes (service delivery, support).
The security section describes the technical and organizational measures the processor implements to protect personal data: encryption, access controls, security training, incident response. The measures should match the risks of the data being processed. GDPR Article 32 requires appropriate security proportionate to risk.
The sub-processor section covers the processor's use of its own vendors to help process the controller's data. Common sub-processors include cloud infrastructure (AWS, Azure), email delivery providers, customer support tools. The DPA typically requires notice of sub-processor changes and gives the controller the right to object.
The breach notification section defines when and how the processor notifies the controller of a data breach. Typical requirements include notification within 24 to 72 hours of discovery, specific information required in the notification (nature of breach, data affected, measures taken), and ongoing updates as the investigation progresses.
The audit rights section gives the controller the right to audit the processor's compliance with the DPA. Common patterns include annual audit rights, acceptance of third-party audit reports (SOC 2) in lieu of customer audits, and notice requirements for scheduled audits. The specifics vary by vendor policy.
The return or deletion section covers what the processor does with personal data when the contract ends. Standard options include returning data to the controller, deleting data within a specified window, or retaining data for a defined period for legal or operational purposes. The controller usually gets to choose.
DPAs often go through negotiation during enterprise procurement. The six negotiation points below are the ones that come up most often.
Some buyers want prior written approval of every sub-processor change. Vendors prefer notification with a right to object. The negotiation usually lands on specific thresholds: notification for most changes, prior approval for sub-processors with heightened risk (payment processors, large data stores).
Buyers often want 24-hour breach notification. Vendors typically commit to 72 hours. The specific number is negotiable. The practical standard is notification "without undue delay" with specific commitments on the information required and the follow-up pattern.
Some buyers want in-person audit rights. Most vendors offer acceptance of third-party audit reports (SOC 2 Type II) as the primary audit mechanism, with in-person audits reserved for specific triggers (breach, suspected non-compliance). The compromise is standard in mature B2B SaaS.
Buyers with regulatory or policy constraints often require data residency in specific regions (EU, US, specific countries). Vendors offer region selection where their infrastructure supports it. The negotiation turns on what the vendor can actually deliver, not just what the buyer wants.
For EU personal data processed outside the EU, the DPA usually includes Standard Contractual Clauses. The 2021 SCCs replaced the earlier versions and are the current standard. Buyers and vendors negotiate which SCC module applies based on the controller-processor relationship.
Liability for data breach is often negotiated between the DPA and the master services agreement. Standard patterns include liability capped at a multiple of fees paid, specific carve-outs for willful misconduct, and indemnification for third-party claims arising from the processor's breach. The specific numbers are enterprise-specific.
The DPA request and signing process should be routine, not a project. The six-step pattern below is the one most mature SaaS procurement follows.
Buyers typically request the vendor's DPA during security review, alongside the SOC 2 report and compliance documentation. The DPA request is routine and should not require special escalation. Vendors with on-request DPAs available in a trust center move faster through this step.
Mature vendors have a standard DPA template that covers the common requirements. The template is usually reviewed by both parties with specific negotiation on the points above. Vendors who have to draft each DPA from scratch slow procurement by weeks.
Legal teams on both sides review the DPA. Buyer legal checks compliance with the buyer's policies. Vendor legal checks consistency with the vendor's obligations. Legal review typically takes 1 to 3 weeks depending on the complexity of the negotiation.
Negotiation typically focuses on specific clauses (sub-processor consent, breach timing, audit rights) rather than redlining the whole document. Vendors who accept redlines on standard clauses move faster. Vendors who require their exact template unchanged slow deals and often lose them.
The DPA gets signed alongside the master services agreement and becomes an attachment or addendum. Both documents are usually e-signed at the same time. The DPA stays in effect for the duration of the main contract and is renewed if the main contract is renewed.
After signing, the DPA creates ongoing obligations: breach notification, sub-processor change notice, data return or deletion at contract end. Both parties operate under the DPA throughout the contract term. The DPA is not a one-time compliance artifact; it is a living contract.
Strkr maintains a standard DPA available on request through the Strkr team. The DPA covers GDPR Article 28 requirements, includes Standard Contractual Clauses, and is designed for enterprise procurement workflows.
Data Processing Agreement, or Data Protection Addendum in some contexts. The two terms are used interchangeably for the contract between a data controller and a data processor that governs how personal data is handled. GDPR Article 28 defines the required content of a DPA.
Whenever a vendor processes personal data on behalf of a customer. For B2B SaaS, this is most vendors. GDPR requires a DPA for processing EU personal data. CCPA and similar US state regulations require similar contract terms. Enterprise procurement teams typically require a DPA before contract signing.
A privacy policy is a public document explaining how a company handles personal data. A DPA is a contract between a controller and a processor that creates specific legal obligations. The two serve different purposes: privacy policy is user-facing disclosure; DPA is a vendor-to-customer contract.
A DPA is required for GDPR compliance when a vendor processes EU personal data. The DPA covers Article 28 requirements. Full GDPR compliance requires additional practices: lawful basis for processing, data subject rights handling, DPO appointment where required, data protection impact assessments for high-risk processing.
If they process personal data on behalf of a customer, yes. Small vendors sometimes resist DPAs or push back on standard clauses. Enterprise buyers rarely accept the resistance. A small vendor without a working DPA process will struggle to win enterprise business. Standard DPA templates are affordable to establish.
Strkr has a standard DPA available on request through the Strkr team. The DPA covers GDPR Article 28 requirements, includes Standard Contractual Clauses for EU data transfers, and is designed for enterprise procurement workflows. Request during security review alongside the trust center documentation.
Typically the DPA is signed once alongside the master services agreement and remains in effect for the contract term. Renewal of the master contract usually carries the DPA forward. Material changes to the DPA (new sub-processors, new processing scope, regulatory updates) are managed through notification rather than full re-signing.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
