# Data processing agreement: when the buyer asks for a DPA, and how to keep the close date https://salesbond.app/blog/data-processing-agreement-sales-deal/ Published: 2026-10-22 · Updated: 2026-10-22 A data processing agreement (DPA) is the contract between the controller, who decides why and how personal data is processed (usually your customer), and the processor, who processes it on the controller’s behalf (usually you, the vendor). In a B2B sale it surfaces at the contract stage, and the one asking is the buyer’s lawyer, security lead or procurement, not your champion. Keep a standard DPA ready, send it the same day, and track three statuses and one dated task on the deal. This is written for salespeople and sales managers, and it’s about process, not law. Where we say what a DPA contains, we quote the regulation and link to it. ## The deal that sat in legal for three weeks over one attachment Dana sells a scheduling product to a logistics company with a few hundred employees. On October 2 the MSA goes to the buyer’s in-house counsel. On October 6 counsel replies: two light redlines, and a last line that reads “please also send your DPA for review.” The company has no DPA of its own. The founder finds a template, reads it over a weekend and sends it on October 13. Two days later the buyer’s security lead asks for the subprocessor list referenced in the annex, and nobody at the vendor has ever written one down. It takes until October 20 to put together. The DPA is signed on October 27. The close date in the CRM said October 17. It moved twice, the stage never changed, and at two pipeline reviews the line for this deal was “in legal”. Nothing in that story was a legal problem. The buyer never objected to a clause. Three weeks went to finding a document, writing a list and waiting on internal replies, and none of it was visible on the deal. ## What a data processing agreement is (GDPR Article 28) A data processing agreement is the contract Article 28(3) of the GDPR has in mind when a processor handles personal data for a controller: processing by a processor “shall be governed by a contract or other legal act” that is binding on the processor and sets out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the obligations and rights of the controller. The same paragraph requires that the processor handles personal data only on documented instructions from the controller ( [GDPR, Article 28](https://gdpr-info.eu/art-28-gdpr/)). Article 28(2), one paragraph up, explains why the security lead in Dana’s story wanted a list: “The processor shall not engage another processor without prior specific or general written authorisation of the controller,” and under a general authorisation the processor has to tell the controller about intended changes so the controller can object. Those other processors are your subprocessors, the vendors that touch your customers’ data on your behalf: hosting, email, the support desk, analytics. To see what one looks like, gdpr.eu publishes a [data processing agreement template](https://gdpr.eu/data-processing-agreement/), adapted, as the page says, from the ProtonMail DPA. It is a template, and the site itself says nothing on it constitutes legal advice. ## Does every B2B deal need a data processing agreement? This is the one question we leave to someone else. The gdpr.eu explainer states the rule plainly: if your organization is subject to the GDPR, “you must have a written data processing agreement in place with all your data processors” ( [gdpr.eu](https://gdpr.eu/what-is-data-processing-agreement/)). Whether that describes a particular deal is for your lawyer to say. From the sales side the answer barely matters, because once the buyer’s counsel asks, the deal waits for the DPA either way. The same regulation is behind the other GDPR paperwork reps run into, such as a [GDPR deletion request in Pipedrive](https://salesbond.app/blog/pipedrive-gdpr-deletion-request/). Different document, different owner. ## When it shows up and who asks Not before the demo. The pre-demo document is the NDA, and we covered [when a sales team should sign an NDA before a demo](https://salesbond.app/blog/nda-before-demo-sales-team-pipedrive/) separately. The DPA shows up when the contract does, and it comes from one of three people who each want something different. The buyer’s lawyer or data protection officer asks for it alongside the MSA redlines. They read the clauses, and they’re the ones who will say “we’ll send ours” instead. The security or IT lead asks for it after the security questionnaire, and often the questionnaire has a row that says “attach your DPA”. That’s why the two get confused. You answer a questionnaire and nobody signs it; a DPA is a contract both sides sign. Your subprocessor list feeds both. The security lead doesn’t read the clauses, they read the annex: subprocessors and technical measures. When questions come back, they usually come from here. Procurement asks for it as a line on a vendor onboarding checklist. They want a PDF in thier system and a box ticked, and they won’t release the purchase order without it. Knowing who asked tells you whose queue the document sits in and what “done” means for that person. So two questions go back the same day the request arrives. “Will you sign our standard DPA, or do you need us on yours?” and “Is the DPA signed with the MSA, or separately, and by whom?” Either side can draft it: Article 28 lists what the contract sets out, not who writes it. Some buyers attach the DPA to the MSA as an exhibit and sign once, others sign it separately, sometimes with a different signatory, and a separate signature is a separate date. How the MSA, the SOW and the order form divide up between sales and legal is in [master service agreement vs SOW vs order form](https://salesbond.app/blog/master-service-agreement-sow-order-form-sales-team-crm/). The wider set of questions for any document sitting with the buyer’s reviewers is in [deals stuck in legal and procurement](https://salesbond.app/blog/deals-stuck-in-legal-procurement-pipedrive/). A DPA request is not a sign of trouble. It means the buyer has started onboarding you as a vendor, and the rep who hears it as an obstacle is the rep who sends it late. ## Get the standard DPA ready before anyone asks We think a company that sells to other businesses should have its standard DPA and its subprocessor list ready before the first buyer asks, and the salesperson should never be the one assembling either. Its a company task with a named owner, done once. What sales needs is a place to find three things. The standard DPA as a PDF, with the version date in the filename. Legal writes it, and nobody else edits it. The subprocessor list: the vendor’s name, what it does for you, where it processes the data. Whoever runs infrastructure or operations owns it and reviews it when a new vendor is added, not when a buyer asks. Of the three, this is the one the buyer’s security lead actually reads, and the one Dana’s company didn’t have. A one-line policy for the buyer’s paper. Something like: “Send ours first. If they insist on theirs, it goes to Priya, and she sets the date.” With those in place the rep’s part is short. Send the standard DPA the day the request lands, with the subprocessor list attached. Don’t edit a clause, even a “small” one, and don’t explain what a clause means; forward the question to the owner and tell the buyer who is answering and by when. On a call, “it’s our standard processor agreement under Article 28, and the subprocessor list is attached” is as far as sales goes. Why ours first? Their paper means your legal owner reads a new document, and then redlines travel both ways. In our experience a complete DPA that arrives the same day gets fewer questions back than the same document a week later with the annex blank. The content is identical. The reviewers formed their view of the vendor from the speed. ## Fields and a task on the deal: requested, sent, signed, owner, date Whatever CRM you run, this is one custom field on the deal, one task and one note. We keep it out of the stages on purpose: the deal is in redlines, security review and procurement at once, and stages are linear. - **DPA**, a single-option field with three values: Requested, Sent, Signed. Blank means nobody has asked. We don’t add “Under review”, because a DPA that was sent and not signed is under review by definition. Every open deal where DPA is Requested or Sent is the list that matters on Monday. - **DPA paper**, optional: Ours or Theirs. Theirs takes longer, and you want to see those deals together. - A task on the deal, owned by whoever does the next thing, not the rep by default. If the founder sends the standard DPA, the founder owns it; if Dana is chasing counsel, Dana does. The due date is your own send date or the date the buyer promised, and the subject names the buyer-side person: “DPA back from their counsel (Mark), owner: Dana”. When the status moves, close the task and create the next one. - A note with who asked, whose paper, and the promised date, plus the PDF you actually sent, so the next person sends the same version. If you already built the Paper blocker field from the legal and procurement article, add “DPA” as one of its values instead of running a second system. The rep updates it the day the status changes. The manager checks it once a week, from the the filter, not by asking each rep. ![Deal card with DPA fields and a task, beside a timeline of the DPA request from Oct 6 to signing on Oct 27](https://salesbond.app/wp-content/uploads/2026/10/data-processing-agreement-sales-deal-2.png) ## What to put in the forecast while the DPA is open The honest forecast line is a sentence, not a stage name: “Waiting on DPA. Ours, sent October 13, with their counsel, promised back October 24, owner Dana.” If the rep can say that sentence, the deal is being managed. If the rep can’t name the buyer-side person who has the document, the DPA isn’t what the deal is waiting on, and the pipeline review should go looking for the real reason. How far the open DPA should move the close date depends on where it is. Your paper, sent, no questions back: this is days. Keep the close date, make sure the dated task exists, and chase on the promised date, not before. Their paper: treat it like redlines. The close date follows the date your legal owner gives you, not the one the champion hopes for. Move it once, with the reason in the note. Questions back about subprocessors or technical measures: the deal has gone from legal back to security, with a different owner on the buyer side and a different clock. How to set the close date in that case is the same as for a questionnaire, and we wrote it up in [a security questionnaire landed mid-deal](https://salesbond.app/blog/sales-security-questionnaire-pipedrive/). Dana’s deal failed quietly. No stage change, a close date that stayed put, and no activity because the document was “with them”. We build SalesBond, a sales management layer on top of the CRM a team already uses: Pipedrive, HubSpot, Salesforce or Zoho CRM. It flags a deal whose expected close date has passed with no next activity scheduled, and states that reason to the manager. It doesn’t read the DPA, and it can’t tell you whether their counsel is on holiday. It does keep the deal from sitting unnoticed until the second pipeline review. [Check your CRM with SalesBond](https://salesbond.app/). Before the next request lands, ask one question internally: who owns our standard DPA, and who owns the subprocessor list? If either answer is “nobody”, that’s the first task to create.