Salesforce Data Processing Addendum (DPA) Guide: Ensuring Compliance and Negotiating Privacy Terms

Salesforce’s Data Processing Addendum (DPA) is a critical contract for enterprises using Salesforce’s cloud services under GDPR, CCPA, and other data protection laws. This guide breaks down when the DPA applies, what it covers, and how you can confirm Salesforce meets your compliance needs – and importantly, where you may want to negotiate stronger privacy and security terms. We take a compliance-first, practical look at Salesforce’s standard privacy terms, helping you protect your organization’s data and mitigate risks.

What Is the Salesforce DPA and Why It Matters

The Salesforce DPA is a contract addendum that defines how Salesforce, as a service provider (processor), will handle personal data on behalf of your company (the controller). It outlines privacy and security obligations to align with laws such as the GDPR in Europe and the CCPA in California.

When you use Salesforce to store or manage any personal data – whether customer information, employee records, or leads – this DPA kicks in to govern that data processing. It’s not automatic or just paperwork: it’s a key part of keeping your Salesforce usage compliant. For a complete overview, read our ultimate guide to Salesforce Contract Legal Terms.

Salesforce’s standard DPA provides a solid baseline of privacy terms. It incorporates GDPR-mandated clauses (often referred to as the Salesforce GDPR agreement by customers) and includes commitments regarding data security, breach notification, subprocessors, international transfers, and more.

However, no boilerplate can fit every organization perfectly. Regulations differ by jurisdiction and industry. Enterprise customers, especially those in highly regulated sectors or operating globally, should validate that the DPA’s scope and terms meet their specific requirements.

The DPA can often be negotiated – or at least clarified – to plug any gaps. In short, don’t assume Salesforce’s out-of-the-box privacy terms automatically make you compliant.

You need to conduct your due diligence and potentially advocate for improvements aligned with your risk profile.

When Does the Salesforce DPA Apply?

Trigger conditions:

You’ll typically sign Salesforce’s DPA at the same time as your Master Subscription Agreement (MSA) or via an Order Form if you’re purchasing Salesforce services. The DPA applies whenever Salesforce processes personal data for you. In practice, that’s almost always – if you store any identifiable personal information in Salesforce (customer names, emails, case details, etc.), you need a DPA in place.

It’s especially crucial if any data will leave its country of origin (for example, using Salesforce’s global cloud infrastructure to process data from EU residents in the U.S.). Cross-border data transfers, use of add-on Salesforce services, or integrating AppExchange apps that process personal data are all scenarios where the DPA’s protections become vital.

Contract stack clarity:

It helps to understand how the DPA fits into your overall Salesforce contract. Generally, the hierarchy is: Master Subscription Agreement (MSA) → DPA → Service-Specific Terms → Product Documentation. The MSA or main agreement sets the general commercial terms. The DPA then adds or overrides terms specifically for data protection and privacy.

Service-specific terms (for Marketing Cloud, Slack, etc.) and documents like Salesforce’s Security & Privacy documentation provide more details. Make sure the DPA is attached or referenced in your order paperwork so that it’s legally binding.

It’s also wise to ensure every Salesforce affiliate or product you use is covered – sometimes large enterprises sign multiple order forms, and each should be subject to the DPA.

Salesforce entities as processor/subprocessor:

Salesforce operates through various legal entities worldwide. Be clear on which Salesforce entity is your contracting party (the processor) and which ones might handle your data as subprocessors.

For example, a European customer might contract with Salesforce UK or Salesforce Ireland (the local Salesforce entity acts as the primary processor), while Salesforce, Inc. (the U.S. parent company) and other Salesforce affiliates (like Salesforce India or Salesforce Australia for support or development) act as subprocessors. The DPA usually contains a list or link to Salesforce’s affiliates and infrastructure providers.

Confirm that the correct Salesforce entities relevant to your region are identified – this matters for compliance with local laws and for knowing who is legally on the hook for protecting your data. If you’re in a regulated industry or country with data residency laws, ensure the right Salesforce entity is party to the agreement and others are properly subprocessor-designated.

Read about how to negotiate Salesforce MSA, Salesforce MSA Decoded: Top 10 Clauses Enterprises Must Negotiate.

Data Security Commitments: What to Expect and Verify

A major part of Salesforce’s privacy terms involves its data security commitments.

Salesforce touts robust security, but as a customer, you should verify and, if needed, firm up these assurances in the contract:

• Encryption in transit and at rest: Salesforce’s platform encrypts data in transit (e.g. data moving between your users’ browsers and Salesforce) and at rest in Salesforce’s databases. This is a baseline expectation. Check that the DPA or security documentation explicitly confirms encryption for the type of Salesforce products you use. Also, evaluate if you need enhanced encryption: Salesforce offers Platform Encryption (part of Salesforce Shield), which lets you manage encryption keys and even bring your own keys for certain data. If you handle sensitive personal data, negotiating use of customer-managed keys can be a strong supplementary measure – it gives you more control (and can be a GDPR/Schrems II safeguard, since encrypted data is less accessible to foreign authorities).
• Tenant-level security controls: The DPA will state that Salesforce maintains “appropriate technical and organizational measures” to protect data. In practice, many security measures are also in your control as the customer. Verify what configuration options you have: role-based access controls, single sign-on and multi-factor authentication for your users, IP range restrictions, field-level encryption, and so on. Salesforce provides an array of security features, but you must turn them on or use them correctly. From a compliance standpoint, ensure your team uses these tools – for example, least-privileged access for users, regular permission reviews, and secure integration settings. The DPA’s promises won’t help if a misconfiguration on your side causes a breach.
• Audit logging and monitoring: Strong security includes monitoring for unusual activity. Salesforce’s platform has logging capabilities (e.g., login history, field history, and event monitoring logs if you have that add-on). While the DPA might not detail logging, you should confirm that you can access logs of data access and changes. If audit logs are critical for your compliance (e.g., you need to prove who viewed or changed a record), ensure you have the correct Salesforce edition or add-on. You might negotiate for audit rights – the ability to request certain security audit logs or reports from Salesforce, especially if you don’t have full access on your own. At a minimum, Salesforce holds various certifications (e.g., ISO 27001, SOC 2) that involve external audits – request the latest reports and ensure that the contractually requires Salesforce to maintain these certifications or equivalent security assessments.
• Certifications vs. contractual controls: Salesforce’s participation in assurance programs (like ISO standards, SOC 1/SOC 2 reports, PCI compliance, FedRAMP for government cloud, etc.) is a good sign. However, certificates alone don’t replace contractual obligations. Use those certifications as evidence of Salesforce’s security, but also anchor key expectations in the contract. For example, it’s great that Salesforce is ISO 27001 certified – but you also want the DPA to explicitly require Salesforce to maintain industry-standard security measures, update them as threats evolve, and promptly address any vulnerabilities. The DPA’s security exhibit (often called the Security, Privacy and Architecture Documentation) lists technical measures – review it closely. If you spot gaps (maybe around specific encryption standards, or data segregation in multi-tenant environments), raise them.
• Security incident and breach notification: Under GDPR and most laws, if Salesforce has a data breach that affects your data, they must inform you “without undue delay.” Salesforce’s DPA includes an obligation to notify customers of a data breach promptly after they become aware. As a customer, you should insist on clarity here – what does “promptly” mean? It’s wise to negotiate a specific breach notification SLA, such as initial notice within 24 or 48 hours of Salesforce detecting any personal data breach, with updates as they learn more. Time is of the essence because you (the controller) may need to notify regulators or individuals within strict timelines (GDPR says 72 hours for regulators in many cases). Ensure the DPA defines the content of breach notices too: you’ll want to know the nature of the incident, what data was involved, who is affected, remediation steps, etc. Also, set up clear communication paths: ensure Salesforce has your 24/7 contact information for security incidents, and you have theirs (you don’t want an email going to an unattended inbox in an emergency). A well-defined breach cooperation clause is another thing to look for – Salesforce should agree to cooperate with your investigation and regulatory responses, not just send a templated email.
• Penetration testing and vulnerability management: Enterprise customers often ask how Salesforce tests and hardens its systems. Salesforce (as a major cloud provider) performs regular penetration tests and security reviews of its infrastructure and applications. They also likely run a bug bounty or have internal teams trying to find weaknesses. While the DPA might not detail this, you can request information or summaries about their vulnerability management program. In negotiation, consider asking for commitments that critical vulnerabilities will be patched within a certain timeframe or that you’ll be informed if any major security issues arise that aren’t yet patched. Some customers even negotiate the right to conduct limited independent testing (e.g., application testing on their own org, within permitted guidelines) or to receive the results of Salesforce’s third-party pen tests. At the very least, ensure the contract doesn’t prohibit security testing of your own Salesforce environment (following Salesforce’s policies, of course).
• Customer audit and assessment rights: Cloud vendors are hesitant to allow individual customer audits (since Salesforce can’t have 1,000 clients all inspecting its data centers). Instead, they offer those third-party audit reports and certifications. Still, if you have significant regulatory requirements (such as banks or governments), you may be able to negotiate a more direct audit right. This could be phrased as: you may audit Salesforce’s controls through a mutually agreeable process, maybe limited to once a year, and often using a third-party auditor or by attending a Salesforce-arranged audit day. Even if Salesforce won’t budge on direct audits, ensure you have the right to request additional information or clarification on their security practices beyond just the generic documentation. Clarity on cost-sharing for any audits is also useful (often the customer must bear costs if they insist on an on-site audit).

In summary, verify the security promises in Salesforce’s DPA against your own standards. Don’t assume everything is covered – check encryption, access control, monitoring, breach handling, and audit provisions.

If anything is murky, get it defined, and use your leverage to negotiate stronger terms for critical items.

Data Residency and Regional Hosting with Salesforce Hyperforce

Global enterprises often worry about data residency – where their Salesforce data is stored and processed. Salesforce’s answer to this is Hyperforce, an architecture that allows Salesforce instances to run on public cloud infrastructure in various regions (for example, AWS in specific countries).

This is a game-changer for hosting options, but you need to understand the nuances:

Data residency vs. sovereignty vs. localization: These terms are related but distinct. Data residency generally means the physical location where data is stored at rest. For example, you might require that all your Salesforce records reside in data centers within the EU or within a specific country. Data sovereignty is about legal control: which country’s laws apply to that data. Data stored in Germany falls under EU/German jurisdiction (and could still be subject to foreign access requests if, say, a U.S. company can access it). Data localization refers to laws that mandate data must stay in a certain location (usually within national borders), often for sensitive sectors. It’s important to parse these differences: selecting a local region in Salesforce addresses residency at rest, but you must also consider sovereignty issues (who can access it under what law) and whether any data leaves that locale during processing.

Hyperforce regional hosting:

Salesforce Hyperforce allows customers to choose a specific region (such as AWS Frankfurt for Germany, or AWS Sydney for Australia) to host their Salesforce org.

This means your Salesforce data (records, files, and metadata) is stored and processed in that region’s data centers. “In-region” in the context of Hyperforce generally means the primary storage and compute happen locally. For example, an org on Hyperforce in France will keep its data at rest in France.

This helps meet data residency requirements and can reduce latency for local users. However, in-region does not automatically mean absolutely no data ever leaves. You should inquire about things like backups and support access: Does Salesforce replicate any data out of region for disaster recovery? (Some services offer an optional cross-region backup – if you enable that, it would copy data elsewhere.)

Additionally, when Salesforce support personnel outside the region need to assist, can they access the necessary data? Salesforce has committed that with Hyperforce, even support can be regionalized in many cases, but customers should get clarity on how “stickily” their data stays put.

If data residency and localization are critical for you (say you’re in finance, government, or healthcare with strict local mandates), consider negotiating specific terms:

• Ensure your contract states that Salesforce will host your data in [the chosen country/region] and will not move it elsewhere without consent.
• If you require all support to be local (e.g., only EU support staff can handle an EU org’s data), ask for that in the DPA or support agreement. At minimum, restrict “routine” remote access: e.g., normal maintenance should not pull data outside the region. If there’s an exceptional case requiring foreign support, set up a procedure (like you provide case-by-case approval).
• Document any exceptions or escape hatches. For instance, if certain lesser-used Salesforce features aren’t yet available in your region and might process data in the U.S., you should know and agree to it. The DPA’s fine print or the Hyperforce documentation might list such exceptions.
• Require notice for changes in the hosting location. Suppose Salesforce ever plans to shift your org to a different data center or region (perhaps for load balancing or new infrastructure). In that case, they should give you advance notice and an option to object or migrate out.

When discussing Hyperforce and data residency, it’s also worth considering performance vs. compliance. Hyperforce can improve latency for users in-region and ease compliance concerns, but it may incur additional costs or not be available for all Salesforce products.

Balance your needs, and if data residency is a top priority, negotiate that upfront. (For more details on Salesforce’s regional architecture and how Hyperforce works, see our in-depth Pillar 2 article on Hyperforce.)* (Internal Link to Hyperforce pillar page)

Subprocessors: Transparency and Control over Salesforce’s Third Parties

Modern cloud services rely on subprocessors – subcontractors and affiliated companies that help provide the service.

In Salesforce’s case, subprocessors include both its own corporate affiliates and external providers (for example, Amazon Web Services is a subprocessor when you’re on Hyperforce, since AWS hosts the infrastructure; other subprocessors might include companies that assist with support, data center operations, or specific features).

Salesforce does maintain a published list of subprocessors and infrastructure locations for each of its services. You can typically find this on Salesforce’s trust or compliance website under Infrastructure and Sub-processor Documentation.

It’s good practice to review that list for any surprises (e.g., is any data stored in a country you didn’t expect, or is a particular third-party involved in handling your data?). Salesforce’s DPA commits that Salesforce will impose the same data protection obligations on any subprocessor as contained in the DPA – in other words, subprocessors must meet or exceed Salesforce’s own commitments for security and privacy.

Also, Salesforce remains liable for its subprocessors’ actions. This is important: if a subcontractor foul-up causes a breach, Salesforce can’t just shrug it off; contractually, they’re on the hook to you as the main vendor.

Notification of new subprocessors:

One of the key rights customers have is to be informed when Salesforce plans to add or change a subprocessor. The DPA typically states that Salesforce will notify customers (often via email or a portal notification) before a new subprocessor is authorized to process your data.

You usually have the ability to subscribe to these subprocessor change alerts – make sure someone in your company (IT or compliance) is subscribed so you don’t miss it. The notice period might be relatively short (e.g., Salesforce might inform you 10 days or 30 days before the new subprocessor goes live).

Right to object:

What if you don’t like a new subprocessor? The DPA provides a process to object on reasonable grounds. Typically, you must lodge your objection in writing within that notice window. Salesforce will then attempt to resolve your concerns – for example, by clarifying the subprocessor’s role, ensuring additional safeguards, or, in some cases, maybe offering to keep your data on an alternative infrastructure if possible.

In reality, large cloud providers have standardized subprocessor lists, and it’s rare to get an individual exemption. If Salesforce can’t accommodate your objection, the ultimate “remedy” in the DPA is that you can terminate the Salesforce service that’s affected and get a refund for any prepaid fees for the remaining term.

That’s a drastic step, of course, but it’s there largely for legal completeness.

Negotiation aims for subprocessors: As a customer, you may want to push for:

• Longer notice and transparency: Try to secure a commitment for a longer notice period (e.g., 60 days before a new subprocessor is used) to give you more time to assess the impact. Also ensure Salesforce’s subprocessor list stays up-to-date and readily available. You might even request that Salesforce provide you an updated list annually upon request, in case you need it for audits.
• Good-faith objection rights: Strengthen the language around objections. Rather than a perfunctory “you can terminate if you object,” ask for language that Salesforce will, in good faith, work with you to find a solution. This could include using an alternate region or subprocessor where feasible, or implementing additional controls to mitigate the risk that concerns you.
• Contractual assurances: Confirm in the DPA that Salesforce must flow down all key obligations (confidentiality, data security, breach notice, etc.) to all subprocessors. This is usually already there, but it’s worth double-checking. Also, require that Salesforce will notify you promptly if a subprocessor’s compliance status changes (for instance, if a subprocessor had a certification like ISO or Privacy Shield that gets invalidated, or if Salesforce stops using a subprocessor due to a security issue – you’d want to know).

Ultimately, visibility into Salesforce’s supply chain of data processors is vital for your compliance. Use the DPA to ensure you’ll always know who is holding or touching your data, and maintain the right to vet those additions.

International Data Transfers: SCCs, Schrems II, and Safeguards

Suppose you’re using Salesforce in a way that personal data from one country is accessed or stored in another (which is very common with cloud services). In that case, you need to address international data transfers.

This is especially a pressing issue for EU personal data being sent to the U.S., in light of the Schrems II ruling.

Standard Contractual Clauses (SCCs):

Salesforce’s DPA incorporates the latest European Commission Standard Contractual Clauses by reference (usually as a schedule or annex). These are legal clauses approved by the EU to legitimize personal data transfers from the EU to “third countries,” such as the U.S. Salesforce has updated its DPA to include the 2021 SCC modules applicable to controller-to-processor transfers.

In practice, when you (as an EU data exporter) sign Salesforce’s DPA, you are also signing the SCCs with Salesforce, Inc. (the primary data importer in the U.S.) and Salesforce’s other relevant entities.

Make sure the DPA signature process is followed so that the SCCs are considered executed – Salesforce often pre-signs them, and you just need to countersign or agree via the DPA.

Schrems II and Transfer Impact Assessments (TIA):

The Schrems II decision (2020) invalidated the old EU–US Privacy Shield and put the onus on companies to assess transfers to countries like the U.S. Even with SCCs in place, you (the exporter) must evaluate if there’s a risk that local laws (e.g., U.S. surveillance laws) could impinge on data privacy, and if so, implement supplementary measures.

Salesforce, being a large provider, has taken steps to help here. Notably, Salesforce has Binding Corporate Rules (BCRs) approved for its group – these are another safeguard mechanism for intra-company transfers.

Additionally, Salesforce has likely conducted its own internal assessment of U.S. law and implemented measures such as challenging government access requests and publishing transparency reports.

Ask Salesforce if they have a Transfer Impact Assessment document or guidance for customers – many providers now share whitepapers that explain how they handle government requests, encryption, etc.

Supplementary measures: If your risk assessment requires extra protections, consider:

• Encryption and key location: As mentioned earlier, with Salesforce Shield, you can ensure that certain sensitive fields are encrypted and you retain the keys (potentially even storing them only in the EU). That way, even if data were accessed by a U.S. court order, without the key, the data is gibberish. Pseudonymization of data before sending to Salesforce is another measure (though not always practical).
• Access controls and policy: Salesforce’s DPA states that they will not disclose data to government authorities unless legally compelled, and they’ll redirect requests to you when possible. This is good. You might also want it to say Salesforce will challenge any overbroad or unlawful request (which Salesforce typically commits to in their public statements). Ensure that if Salesforce must hand over data, they’ll only give the minimum necessary.
• Transparency: Check if Salesforce provides a transparency report (they do publish one annually) and consider if you want contractual language that you’ll be notified (if legally allowed) of any government demand for your data. Under SCCs, Salesforce has to try to notify you unless prohibited by law.

When negotiating, if you have particular transfer concerns, you could add clauses: for example, “Salesforce will, upon request, provide Customer with relevant information about its data transfer safeguards and any assessments of the adequacy of measures, to assist Customer in its own compliance.”

Additionally, clarify responsibilities: the DPA may state that each party is responsible for complying with transfer laws. Make sure you know what you have to do – usually, it’s to sign the SCCs (done via DPA) and possibly document your assessment.

If your regulators expect you to keep a record, have Salesforce provide you with the needed info (subprocessor list with locations, technical measures, etc.) to support your TIA documentation.

In summary, Salesforce has the legal mechanisms (SCCs, BCRs) in place, but you must still be proactive. Understand where your Salesforce data might travel, use available controls like Hyperforce or encryption to limit exposure, and ensure the DPA/SCCs combo is fully executed and up-to-date (watch out for regulatory updates, like the new EU-US Data Privacy Framework in the future – the DPA might evolve accordingly).

Data Subject Rights, Data Exports, and Deletion Commitments

Compliance isn’t just about keeping data safe – it’s also about data governance throughout the lifecycle.

Two crucial aspects are fulfilling data subject rights requests and handling data at the end of your Salesforce use (exports and deletion).

Data Subject Rights (DSRs):

Laws like GDPR grant individuals rights to their personal data – to access it, correct it, delete it, restrict processing, or export it (portability). As the controller, your company is responsible for responding to these requests. Salesforce, as a processor, should assist you.

The DPA typically states that if Salesforce directly receives a request from your customer or user, they will forward it to you and not respond on their own (which is good – you don’t want Salesforce deciding how to handle your users’ data requests). Ensure your internal process is set: e.g., if someone asks Salesforce, “delete my data”, Salesforce will let you know so you can take action.

Salesforce’s platforms have features to help with DSRs. For example, you can search and retrieve all records about a person, correct inaccuracies in the database, or delete a contact from your system. Check if there are any limitations – some Salesforce products (like Marketing Cloud, which is separate from the core CRM) might have different tools for deletion or anonymization.

It’s wise to run a test: how would we actually delete someone’s data from Salesforce if asked? Make sure it’s feasible and documented. If any part of Salesforce makes this hard (for instance, certain logs or backups that hold personal data), clarify in the contract how those will be handled.

Also consider timeline: GDPR says you must respond to DSRs typically within one month. Ensure Salesforce asa processor is obliged to assist “without undue delay” when you need something from them (like retrieving data that you can’t easily get yourself).

Data export on termination:

Eventually, you may leave Salesforce or decide to move to a different system. The DPA addresses what happens upon termination of the services.

Usually, you have the right to get your data back. In practice, you should plan how to export all your Salesforce data well before the contract ends. Salesforce provides various export tools (reports, data export services, APIs). The DPA may not specify formats, but data can commonly be exported in CSV format or via database backup for certain products.

Negotiate for a reasonable data retrieval period: for example, Salesforce might allow 30 days after contract termination for you to download your data (some MSAs state that after 30 days post-termination, the provider may delete data). You might ask for a longer window if you have huge amounts of data or complex exports – maybe 60 or 90 days, depending on your needs.

Also, consider assistance: if you’ll need Salesforce’s help (beyond self-service tools) to extract data, try to have that included or at least get a clear quote upfront for such services to avoid surprise costs.

Another angle is cost: Many customers can export data without additional fees using standard functionality. But if you need a custom backup or assistance, Salesforce might charge professional service fees. As a negotiation point, you could insist that basic data export assistance at termination will be provided at no additional cost, or cap the fees for that help. The idea is to avoid a situation where you’re effectively “held hostage” to pay extra to get your own data out.

Data deletion and retention:

Once your contract is over (or when you delete specific data during the term), Salesforce has obligations to delete data from their systems. The DPA states that after termination, Salesforce will delete the customer data in accordance with its procedures and within certain timeframes.

Often, production data is erased shortly after that post-termination window, but backups might linger for some time (commonly, backups are overwritten on a rolling basis – e.g., within 30, 60, or 90 days).

You should get clarity on the exact schedule: how long will it take Salesforce to fully purge your data from all systems, including archives? If you require a certificate of deletion (some regulators or internal policies might want formal confirmation), negotiate that the DPA include providing a written certification that all personal data has been deleted after the process is complete.

One thing to watch for is legal hold scenarios: if your organization is facing litigation or compliance investigations, you might need certain data preserved beyond termination.

Coordinate with Salesforce in those cases – the contract could allow you to request extended retention for specific data if required by law. Just don’t assume Salesforce will keep your data forever; their standard approach is to delete after the contract is done to minimize liability.

Bottom line: Ensure the DPA and your exit plan guarantee you can get your data out of Salesforce in a usable form, that you have enough time to do so, and that Salesforce will then permanently delete the data.

No one likes to think about the breakup during the honeymoon, but in cloud contracts, it’s essential for compliance and business continuity.

Shared Responsibilities: Customer vs. Salesforce Obligations

Using Salesforce involves a shared responsibility model for privacy and compliance. It helps to spell out who does what so nothing falls through the cracks.

Below is a breakdown of key areas and whether it’s on you (the customer/controller) or Salesforce (the provider/processor) – or both – to fulfill certain obligations.

We also indicate how you can verify or enforce each item and whether the term is usually negotiable:

This table clearly illustrates that achieving compliance is a collaborative effort. Salesforce handles the platform’s integrity and global legal mechanics, while you must operate the tools responsibly and fulfill frontline obligations. Use this as a checklist to ensure all boxes are ticked on both sides.

Key Negotiation Levers for the Salesforce DPA

Even though Salesforce uses a “one-to-many” standard DPA, large enterprise customers do have room to negotiate some terms.

Here are key levers and red-line items to consider before you sign:

• Subprocessor Notice & Objection: Ask for a longer notice period (e.g., 30–60 days) for new subprocessors. Insist on being able to object and have Salesforce work with you on a solution. Define remedies if you object – such as offering a different region or terminating the affected service with a refund. This ensures you’re not caught off-guard by an outsourced provider that could raise risks.
• Breach Notification Timeline: Strengthen the incident notification clause. Aim for an explicit commitment like “notify within 48 hours of confirmation of any personal data breach” rather than a vague “without undue delay.” Additionally, ongoing updates will be required as Salesforce learns more, and a full incident report will be provided once the investigation is concluded. Early warning is vital for your regulatory duties.
• Data Residency Commitments: If you need data localized, negotiate it upfront. Get Salesforce to commit contractually to hosting your data in a specified region (using Hyperforce or other means). Include language to restrict data from being transferred or accessed outside that region without prior approval. This can be crucial for GDPR, banking regulations, or public sector rules.
• Export & Deletion Assurances: Lock in your rights around data export and deletion. For example, “Customer may export all Customer Data at any time during the subscription” and “for 30 days after termination, Salesforce will make data available for export at no charge.” Also requires a certification of deletion upon completion. The goal is to avoid any friction or cost in getting your data back and ensuring it’s wiped out when you’re done.
• Audit Rights & Transparency: If your compliance regime needs it, negotiate enhanced audit rights. This could be the right to request an annual meeting to discuss security, to send a questionnaire, or even to conduct an on-site audit or penetration test with reasonable notice. At a minimum, ensure you’ll receive updated SOC1/SOC2 reports or ISO certificates annually. Transparency builds trust and satisfies regulators.
• Support Access Restrictions: Add terms that Salesforce support personnel will only access your data on a need-to-know basis, using least privilege. You can request that measures, such as support sessions, be time-bound and logged. If you have ultra-sensitive data, consider requiring support from a specific region or a vetted team. Having these commitments in writing can prevent inappropriate data exposure during troubleshooting.
• Liability for Data Breach: Push for a carve-out or higher liability cap for data protection breaches. Salesforce’s MSA often has an overall liability cap. Negotiating that if a breach of personal data occurs due to Salesforce’s negligence, the damages related to that breach are not capped (or have a separate, higher cap) can protect you better. Not all vendors will agree, but it’s a point to raise, especially if your risk (fines, lawsuits) could far exceed the contract value.
• Most-Favored Privacy Terms: If possible, include a clause that if Salesforce offers more protective privacy terms to other customers (for example, because of a new law or a large client’s requirements), you can opt into those terms as well. Alternatively, tie it to law changes: the DPA should state it will adapt to any stricter applicable laws – meaning if your country enacts a tougher privacy law, Salesforce will meet those standards for you.
• Material Changes & Termination: Ensure there’s a provision that Salesforce will notify you of any material changes to the DPA or privacy practices. If a change materially degrades privacy or security, you should have the right to terminate the service without penalty. This prevents Salesforce from weakening terms unilaterally over time. Generally, Salesforce doesn’t change the DPA often without reason, but this is a safeguard for you.

Each of these levers is designed to mitigate risk and enhance your control. Know your must-haves versus nice-to-haves. Often, getting a slightly better promise in writing can make a huge difference in a worst-case scenario.

And even if Salesforce won’t agree to some changes (they might say their policy is standard), simply asking puts them on notice that you care deeply about these issues – and they may offer alternative comfort (like a detailed explanation of their practices or a side letter) to satisfy your concerns.

Risk Scenarios to Test Before Signing

To ensure the DPA and your Salesforce setup will truly protect you, walk through a few what-if scenarios. Here are some to consider:

• Multi-Jurisdiction Deployments: If branches in multiple countries use your Salesforce, map out where personal data flows. For example, a US and EU operation both using one Salesforce org – check that the DPA covers both (it usually does via Affiliates clauses) and that transfers between them are addressed. Think about whether users in another might view data from one region and if that’s okay under local laws.
• Mergers, Acquisitions, Divestitures: If your company merges with another or spins off a business unit, how will you handle the Salesforce data? Ensure the contract allows assignment or novation (so the new entity can continue using Salesforce under the DPA) or have a plan to segregate data. You may need Salesforce’s help to split an org’s data or duplicate it. Having clear terms on data portability can save headaches if corporate changes occur.
• Switching Vendors (Exit Strategy): Imagine you decide to leave Salesforce for another CRM in two years. Test how you would export all data, including attachments, chatter posts, logs, etc. Is everything accessible via the API or export tools? Identify any data that might not come out cleanly (maybe some config or metadata). Make sure the DPA’s language on data return covers all these elements, not just “customer data” in the abstract. You want a clean exit with no data stranded or overly difficult to retrieve.
• Regulator Inquiry or Audit: If a privacy regulator or an internal audit asks, “Show us that your Salesforce data is handled properly,” what will you provide? Ensure you have copies of the DPA, any SCCs, Salesforce’s subprocessor lists (and updates you’ve received), and security certifications. You might also need records of your own (like a record of processing activities that lists Salesforce as a processor). The DPA should obligate Salesforce to furnish assistance in complying with regulator requests – check for that clause. Practically, keep a compliance folder with all Salesforce-related documents: the signed DPA, copies of any changes, the Infrastructure & Subprocessor doc version you relied on, etc. This helps demonstrate due diligence.

By running through these scenarios, you can spot weaknesses in the contract or your plan. It’s better to address them before signing. Salesforce’s services are usually long-term investments, so think long-term about what could go wrong or change, and ensure you’re covered.

FAQs: Quick Answers to Common Salesforce DPA Questions

Does the Salesforce DPA automatically make us GDPR/CCPA compliant?
Not automatically. The DPA is a necessary piece – it contains the commitments Salesforce (as your processor) makes under GDPR and CCPA (like using data only on your instructions, assisting with rights requests, etc.). Having it in place is required under GDPR Article 28. However, your organization must still use Salesforce in a compliant manner. You need to configure security properly, choose appropriate data locations, and fulfill all controller obligations (like having a legal basis for the data, honoring deletion requests, etc.). Think of the DPA as a foundation: it enables compliance but doesn’t guarantee it. You should also consider if any additional terms or measures are needed for your specific compliance program.

Can we require Salesforce to host data only in our region (e.g., use Hyperforce)?
Yes – if Salesforce offers a data center or Hyperforce deployment in your region, you can (and should) request that your data be hosted there for residency reasons. Salesforce Hyperforce was created for this purpose: to deploy Salesforce on local cloud infrastructure (like AWS or Azure) in various countries. Using Hyperforce or a specific instance (for example, Salesforce has GovCloud for US government data, or specific EU Operating Zone environments) can ensure data at rest stays in-region. In the DPA or your order form, have it explicitly state the chosen hosting region and that Salesforce will not move your data out of that region. Keep in mind, you may also need to ask about and limit administrative access from outside the region. Suppose Hyperforce is not yet available in the country you need. In that case, you might have to use a nearest region (like EU for a European country not yet covered) – evaluate if that satisfies your requirements or if you need to wait for local availability. In summary, you absolutely can and should discuss data residency needs with Salesforce – they are generally willing to accommodate via their infrastructure options, though certain custom guarantees may require negotiation.

How do we receive notification of new subprocessors, and can we object to them?
Salesforce allows customers to subscribe to notifications about changes to subprocessors (often through their Trust website or a specific email sign-up). Once subscribed, whenever Salesforce plans to add a new subprocessor, you’ll get an email or alert ahead of time. The DPA gives you the right to object to the new subprocessor if you have legitimate reasons (for example, if that subprocessor would access sensitive data and you have concerns about their security or the data’s destination). To object, you usually must respond within a set period (30 days from notice, typically), stating your concerns. Salesforce will then review your objection. While Salesforce is not obligated to drop the subprocessor just for one customer, they might work with you to alleviate the concern – or, if no compromise is possible, you could terminate the affected service. In practice, it’s rare for customers to object unless the new subprocessor introduces a clear compliance issue. But the mechanism exists as a safeguard. Always review those notices and do your risk assessment on any new vendor involved.

What breach notification timelines are realistic to negotiate with Salesforce?
Salesforce’s standard commitment is to notify without undue delay after becoming aware of a data breach. Many customers feel this is too open-ended. It’s reasonable to ask for a specific timeline – commonly 24 to 72 hours for initial notification. Salesforce might push back on an exact hour count, but they understand customers need speed. A practical compromise requires notification “promptly and in any event within 48 hours.” Also, clarify that this is after they confirm a breach of personal data – sometimes there’s a distinction between detecting a security incident and confirming data was impacted. Initial notice can be high-level (just letting you know something happened and they’re investigating), with fuller details to follow. Given Salesforce’s scale, they likely have 24/7 incident response, so getting word within a day or two is feasible. Make sure your own contacts are set up to receive and act on such notices at any time.

How do we ensure data export and deletion meet our policies when we terminate Salesforce?
Plan it out and get it in writing. Before terminating, decide what format you need the data in and test exporting a sample. Salesforce typically allows self-service export of data (like CSV files or via API). If your policy requires a certain format (say, SQL database dumps or a specific archive type), see if Salesforce offers that – if not, you’ll have to convert it on your side. Negotiate the post-termination access period to retrieve data (30 days is common; you might get more if needed). Ensure the DPA obliges Salesforce to delete data permanently after that period (which it does) and to confirm deletion if you ask. You may request that backups are also purged within a fixed timeframe in line with your data retention rules. Essentially, align Salesforce’s process with your internal data retention and destruction policies. If your policies say “vendors must certify data deletion,” then include a clause that Salesforce will provide such certification on request. The key is that there should be no ambiguity about what happens to your data once you’ve closed your Salesforce account – you get your data, then they wipe it out.

What audit rights can we realistically obtain from a cloud vendor like Salesforce?
Realistically, Salesforce won’t allow individual customers to conduct deep on-site audits of their data centers, given the shared nature of the service. However, you can obtain a lot of audit-related comfort in other ways. Salesforce annually publishes third-party audit reports (SOC 1, SOC 2 Type II, ISO 27001 certificates, etc.). You absolutely have the right to get and scrutinize those. If that’s not enough for your regulators, you can try negotiating a right to ask further questions or even to conduct a remote assessment. For example, you might agree that you can perform an audit of compliance by reviewing documentation and maybe interviewing a Salesforce security representative, instead of a physical inspection. Some customers arrange on-site visits to Salesforce offices to discuss security (Salesforce often hosts “trust and compliance workshops” for big clients). Also, you might negotiate an audit clause that says if a regulator explicitly requires that you audit Salesforce, then Salesforce will accommodate that (under confidentiality and scope limits). In summary, while you may not get carte blanche to poke around Salesforce’s servers, you can secure commitments for cooperation and transparency that meet most audit needs.

Are liability caps negotiable for data protection breaches?
They can be, especially if the deal is large or the risk is significant. Salesforce’s standard contract has an aggregate liability cap (often tied to the fees paid). You may want to carve out certain things from that cap – data privacy breaches, confidentiality breaches, or regulatory fines stemming from the processor’s actions. Some companies have been able to negotiate that certain damages related to privacy obligations are uncapped or have a separate, higher cap (such as 2-3 times the contract value). Salesforce might resist uncapped liability (that’s a tough ask for any vendor), but they could agree to a higher cap for specific breaches, or at least not to exclude regulatory fines from direct damages (so if you get fined and it was Salesforce’s fault, you could claim those damages). Always align this with your insurance and risk tolerance – if your potential exposure is huge, it’s worth pushing on this. Even if you don’t fully succeed, the conversation itself often leads Salesforce to reassure you of its security posture (which indirectly contributes to its being careful to avoid those breaches entirely).

Read about our Salesforce Negotiation Services

Do you want to know more about our Salesforce Negotiation Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit