How to use a DPA template

You’re adding more customers to your roster, which means you’re onboarding new team members to serve them better. And now that you have new HR complexities to handle, you bring on an HRIS vendor to manage payroll and organize employee data, like addresses, emails, tax IDs, and banking info. Your executive team has signed off, and everyone is ready to go, until legal counsel asks if the HRIS vendor signed a DPA.

A DPA is essential whenever you’re handing off personal data to a third-party processor. Data protection laws like GDPR and CCPA require data controllers to have a DPA in place with vendor processors to ensure their work complies with regulations.

This article helps founders and procurement teams understand when and why DPAs are necessary and the essential terms they include.

What is a DPA?

A data processing agreement (DPA) is a contract between a client who owns the data (the controller) and the vendor that processes that data (the processor). Also known as a data processing addendum, data protection agreement, controller-processor agreement, or, under the CCPA, a service provider agreement, DPAs are legal documents that determine how the processor can use and store personal data used to carry out a business function.

When to use a DPA

Made popular by data protection acts globally, a data processing agreement is used when a third-party vendor processes personal data on behalf of an organization that owns that data. Typically, you sign a DPA before sharing:

• Customer data, such as names, addresses, bank account numbers, or biometric data being processed by contractors, SaaS vendors, or third-party data processors.
• Employee data, such as tax information, IDs, and Social Security numbers used by payroll or HR processors.
• Vendor-handled data, such as network credentials, support tickets, APIs, and website analytics handled by IT support or marketing and analytics agencies.

As with the UK GDPR, DPAs are mandatory under most U.S. state data protection laws like CCPA and VCDPA when personal data flows from controller to processor.

Types of DPAs

There are three main types of DPAs used by data owners and service providers:

• Controller-to-processor: The standard agreement between companies responsible for the data and the vendors they hire to process it. Controller-to-processor is the most common and most comprehensive type of DPA.
• Processor-to-sub-processor: The agreement between a processor and the downstream vendor they work with, such as a cloud hosting or email service. In many cases, processor-to-sub-processor DPAs are already covered in the controller-to-processor DPAs, but it’s worth confirming.
• Joint controller: An agreement used when two companies jointly determine why and how data is processed—for example, in a joint customer loyalty program. Joint controller DPAs are rare in standard SaaS relationships, and often require an Article 26 joint controller arrangement rather than a DPA.

If your startup is working with multiple vendors processing personal data for you, you need a controller-to-processor DPA with each one. Sub-processor and joint controller DPAs are less common and are less frequently required.

What to include in a DPA template?

Here are the key terms to include in a DPA template.

Essential terms

• Identification of parties: Names of the party that owns the data (the controller) and who processes it (the processor).
• Purpose and scope of processing: States the reason for processing the data—in other words, the function it serves—and how the data can be used.
• Definitions: Characterizes the terms used throughout the agreement. This could include controller and processor (or business and service provider under the CCPA), personal data, processing, etc.
• Documented processing instructions: Lays out the directives a processor must follow when processing personal data for a specified purpose. These are set by the controller.
• Processor responsibilities: Outlines the duties a processor has to protect data, including maintaining confidentiality, training staff, and limiting the scope of use to processing.
• Security of processing: Sets out the technical and organizational measures a processor has in place to protect data from loss, damage, or misuse, and the steps they’ll take to restore it if those measures fail.
• Data subject rights assistance: Describes how the processor and controller will work together to honor an individual’s request to delete or correct their personal data.
• Sub-processor approval and notice requirements: Covers when and why the processor needs permission to hire a sub-processor and how the controller should be notified.
• Duration of the agreement: Says how long the DPA stays in effect.

Protection and end-of-agreement clauses

These clauses define what happens when things go wrong, or the contract ends.

• Personal data breach notification: How quickly the processor must notify controllers of a data breach and what the notification must include. The timing is typically “without undue delay,” and the report usually has to include a description of the incident, what data was compromised, when it happened, and what steps are being taken to fix it.
• Audit rights: The rights controllers have to audit how processors are using personal data. Vendors often resist broad audit rights, but controllers mostly rely on a reasonable annual audit or third-party reports like SOC 2.
• Deletion or return of data on termination: Guidelines for what the processor does with data when their business relationship with the controller ends. The aim is to prevent the processor from keeping personal data indefinitely.
• International data transfer safeguards: What happens to the data if it has to be transferred to an international jurisdiction. There are usually Standard Contractual Clauses (SCCs) for EU/UK customers, and conditional language for other jurisdictions.
• Processing details appendix: Details specifying data types, data subjects, purposes, and retention.

How to customize and sign a DPA

A template DPA doesn't work until it's tailored for the actual parties and data at issue, with specific retention timelines, security measures, and other terms. When DPAs are signed with generic language, the parties can struggle to point to what was actually agreed to when a dispute comes up.

Customizing your template

Be specific. Vague language in a DPA creates dispute risk during a breach or audit. Always include the following information:

• Party details: List the full legal names, business addresses, and entity types for both the controller and processor.
• Effective date: State the exact calendar dates the DPA goes into effect and how long it will be in effect.
• Link to the main services agreement: Provide a link to the main agreement (e.g., the MSA or SOW the DPA is attached to) so it’s clear what services it’s related to.
• Processing details appendix: Add the specifics around legal obligations and processing activities—e.g., categories of data and data subjects, the purpose and types of processing activities, and how long the data will be kept.
• Security measures appendix: Spell out the measures processors must take to protect the data. Some common examples include data backup procedures, regular penetration testing, role-based access controls, and at-rest encryption.
• Sub-processor list and approval mechanism: List the sub-processors that help the processor carry out its activities. State whether general written authorization or specific consent is needed to add other sub-processors in the future.
• Governing law: Name the jurisdiction that governs your agreement, be it Delaware, California, or another state. This is usually the jurisdiction where your business is based and often matches the main services agreement.
• Notice addresses: Include contact information and delivery methods for notices. For example, if there’s a data breach, the DPA should specify if notices should be delivered in writing or sent via email to a specific address.

Review and execute

Before you sign, perform a quality check of the DPA terms:

• Is the processing scope clearly defined? Is it clear what is and isn’t allowed under the DPA? If there’s any confusion about what the processor can use the personal data to do, then the scope is too vague.
• Are security measures concrete? Does the processor explicitly explain how they’ll protect the data? Saying the measures are “commercially reasonable” leaves room for individual interpretation of the terms, which creates potential enforceability issues in the future.
• Are sub-processor rights workable for both sides? The DPA should balance the controller’s ability to manage vendors with enough freedom for service providers to carry out projects. Going too far in either direction limits one or both sides.

Once you’re satisfied, send the DPA for both sides to sign.

How Crosby helps accelerate contracting

Templates work well for standard SaaS and vendor DPAs that require very little customization. They’re great starting points, but if your DPA gets more complex—think custom DPAs from enterprise customers, DPAs with strict Article 28 requirements from EU/UK counterparties, DPAs that process sensitive data categories like health or children’s data, or heavily redlined DPAs—it’s time to tap a lawyer.

Crosby can redline DPAs for you. Custom AI agents analyze the agreement, flagging concerns like vague breach notifications or broad sub-processor approval clauses, and barred attorneys oversee the work. The AI-first model enables Crosby’s fast turnaround times, a few hours on average.

Talk to Crosby about your next commercial contract.

FAQs

Do I need a DPA if I only do business in the US?

Yes, if a vendor is processing personal data for you, and you are based and/or do business in a jurisdiction with data privacy regulations, you need a DPA. With many U.S. states adopting their own privacy laws, it’s best to have one anyway.

What’s the difference between a controller and a processor? (Or business and service provider under the CCPA?)

A controller (or “business” under the CCPA) owns or is responsible for the personal data, while the processor (or “service provider”) uses it to carry out a specific business function. The controller/business determines how the data will be used, and the processor/service provider follows their instructions.

Should I sign a DPA before sharing customer data with a new vendor?

If your customer data includes personal information, you should sign a DPA before sharing it with a new vendor. Make sure to catalog what data is being shared, why and how it will be processed, what to do if there’s a breach, and what happens to the data at the end of the contract.

Do I need a lawyer for every DPA?

Not necessarily. Standard SaaS and vendor DPAs that include routine processing activities and relatively low risk might not need a lawyer. But complex, heavily redlined DPAs with international counterparties, or those that process sensitive data categories, might need a lawyer's review.