A data processing agreement (DPA) and a non-disclosure agreement (NDA) solve different contract problems. This guide explains the difference, shows where their obligations overlap, and provides a reusable contract review checklist for onboarding vendors, negotiating customer agreements, and reviewing renewals.
Overview
The short answer to “DPA vs NDA” is that an NDA usually cannot replace a DPA when one party processes personal data for the other. An NDA is primarily designed to protect confidential information from unauthorized disclosure or use. A DPA addresses personal-data processing responsibilities between parties, including instructions, security measures, subprocessors, assistance with individual rights requests, deletion or return of data, and other privacy obligations.
The documents can be signed separately or included in a broader master services agreement. Some contracts combine confidentiality and data-processing terms, but combining them does not remove the need to cover each subject clearly. The right structure depends on the relationship, the data involved, the parties’ roles, the governing law, and any required transfer mechanism.
| Topic | NDA | DPA |
|---|---|---|
| Primary purpose | Protect confidential business information. | Define how personal data is processed and protected. |
| Information covered | Information identified as confidential or reasonably understood to be confidential. | Personal data processed under the parties’ relationship, plus related processing details. |
| Typical duties | Limit disclosure and use, protect information, and return or destroy it where agreed. | Follow documented instructions, apply security controls, manage subprocessors, assist with rights requests, and handle deletion or return. |
| Security terms | Often describes reasonable protection of confidential information at a high level. | Usually requires more specific privacy and security commitments relevant to the processing. |
| Incident provisions | May require notice of unauthorized disclosure of confidential information. | Addresses personal-data incidents, cooperation, documentation, and notification responsibilities. |
| Subprocessors | Usually not addressed in detail. | Typically requires an approval, notice, or authorization process and flow-down obligations. |
| Regulatory role | Primarily a commercial confidentiality instrument. | Supports compliance with applicable data-protection requirements. |
For a practical compliance workflow, pair the contract review with a documented vendor assessment. The vendor risk assessment template can help connect contract terms with the provider’s security evidence, data access, and operational risk.
Checklist by scenario
When sharing confidential information before a deal
- Identify the parties and whether the NDA is one-way or mutual.
- Define confidential information broadly enough to cover written, verbal, technical, financial, and commercial information where appropriate.
- List exclusions, such as information already public, independently developed, lawfully received from another source, or required to be disclosed by law.
- State the permitted purpose and prohibit use outside that purpose.
- Specify who may receive the information, such as employees, professional advisers, or approved contractors.
- Set security, notice, return, destruction, and survival requirements that match the sensitivity of the information.
An NDA may be sufficient for a discussion involving business plans or source-code concepts where no personal data is exchanged. If names, contact details, customer records, employee information, usage data, or other personal data will be shared, assess whether a DPA or additional data-sharing terms are also needed.
When onboarding a SaaS provider or other vendor
- Confirm whether the vendor acts as a processor, service provider, independent controller, or another legally recognized role for each processing activity.
- Document the subject matter, duration, nature, and purpose of processing.
- List the categories of personal data and the categories of individuals involved.
- Require processing only on documented instructions, subject to any legally required exceptions.
- Review confidentiality commitments for personnel who can access the data.
- Check whether the security description matches the actual service, access model, retention period, and risk.
- Review subprocessors, locations, change notices, and the customer’s ability to object or respond to changes.
- Address support for data-subject requests, investigations, impact assessments, and regulator inquiries where applicable.
- Define deletion or return of data at the end of the service, including backups and legally required retention.
- Align incident notification, cooperation, evidence preservation, and communication duties.
If the vendor processes data across borders, review the applicable transfer mechanism and supporting contractual language separately. Do not assume that a generic confidentiality clause resolves transfer requirements.
When a customer asks your company to sign its paper
- Map the customer’s proposed terms to your actual product architecture and support workflow.
- Check whether the agreement treats your company as a processor for all data or only for defined services.
- Compare security commitments with your existing controls and audit evidence.
- Confirm that response deadlines for incidents, rights requests, and audits are operationally achievable.
- Check that liability, indemnity, and insurance terms are consistent across the DPA, NDA, master agreement, and order form.
- Record exceptions rather than accepting obligations that your team cannot evidence.
This is where contract operations should connect with audit readiness. A SOC 2 readiness checklist can help verify whether promised access controls, incident procedures, and evidence practices are actually in place.
What to double-check
Definitions and scope
Look for conflicts between “confidential information,” “personal data,” “customer data,” and “usage data.” A single dataset may fall within several definitions, each with different handling rules. The contract should make clear which terms control when obligations overlap.
Security language
A promise to use “appropriate security” may be reasonable as a baseline, but it may not be specific enough for a high-risk service or an audit review. Check for references to access control, encryption where appropriate, logging, vulnerability management, resilience, personnel security, and testing. Only accept controls your organization can maintain and demonstrate.
Incident and breach wording
Distinguish between a security event, a confidentiality breach, and a personal-data breach. Check when notice begins, what information the notice must contain, how updates are provided, and which party controls external communications. Avoid promising an exact legal conclusion before facts are known; use a process that allows the parties to investigate and coordinate.
Retention and deletion
Compare contractual deletion duties with backups, support tickets, fraud-prevention records, legal holds, and retention policies. The contract should explain what happens at termination and how exceptions are handled. Your data retention policy checklist can help reconcile contract language with operational practice.
Order of precedence
When the NDA, DPA, master services agreement, security exhibit, and order form conflict, an order-of-precedence clause determines which term applies. Confirm that privacy and security obligations are not unintentionally weakened by a later document or a standard online term.
Common mistakes
- Using an NDA as a privacy agreement: Confidentiality does not by itself define processing instructions, data-subject support, subprocessors, or deletion duties.
- Copying a DPA without mapping the service: Generic schedules can contain inaccurate data categories, locations, retention periods, or security commitments.
- Leaving roles unclear: The parties should assess their actual activities rather than relying only on labels in a template.
- Ignoring the technical team: Legal terms about deletion, access, logs, backups, and incident response should be validated by the people who operate the systems.
- Accepting unlimited audit rights: Define reasonable notice, scope, confidentiality, alternatives, and cost allocation while preserving meaningful assurance.
- Forgetting the renewal cycle: A contract may remain unchanged while the product, subprocessors, analytics tools, or hosting locations change.
- Failing to retain evidence: Keep the signed version, approval record, data map, subprocessor list, security exhibits, and renewal history together.
For organizations building a broader GDPR compliance program, the GDPR compliance checklist for SaaS companies provides a useful companion to contract-level review.
When to revisit
Review the DPA and NDA before signing, whenever the service or data flow changes, and at each renewal. A practical trigger list includes:
- Adding a new product feature that collects, exports, or exposes personal data.
- Changing hosting regions, subprocessors, support locations, or analytics tools.
- Introducing artificial intelligence, profiling, monitoring, or other higher-risk processing.
- Changing retention, deletion, backup, or account-recovery workflows.
- Receiving a customer security questionnaire or a request for updated contractual language.
- Experiencing an incident, audit finding, rights request, or regulator inquiry that reveals a process gap.
- Entering a new market or becoming subject to a different privacy or cybersecurity requirement.
Before the next review, export the current contract inventory and compare each agreement with the live data flow. Confirm the parties and roles, update the processing description, verify subprocessors and transfer terms, test the operational commitments, and obtain approval from the appropriate legal, privacy, security, and business owners. If the documents cannot be reconciled with how the service works today, pause the renewal or record a specific remediation plan. That simple routine turns the DPA vs NDA distinction into an audit-ready contract review process rather than a one-time signing exercise.
