Both, on different agreements. A DPA is signed by the controller and the processor. In a typical B2B SaaS relationship your customer is the controller and you are the processor, so your customer signs the DPA you provide. At the same time you are a controller in your own right for your vendors, so you sign theirs. Most SaaS companies are on both sides of this every week.
This article covers why you sit in both roles, who inside each organisation has authority to sign, whose paper prevails, whether a signature is required at all, and what to record once it is done.
You Are On Both Sides Of This Relationship
The role you occupy is decided by who determines the purposes and means of the processing, not by who is larger or who sends the invoice.
Your customer decides what data goes into your product, why, and for how long. That makes them the controller and you the processor for their data. Downstream, you decide which hosting provider, which error tracker and which email service to use, and for those relationships you are the controller and they are the processor.
There is a third slice people miss. You are also a controller for your own account and billing data — the customer's admin contacts, your usage records, your support history. Your customer is not instructing you on that, you are doing it for your own purposes, and it needs its own basis and its own description. Conflating it with the processor role is what produces DPAs that promise to delete "all data" on termination and then cannot, because some of it is yours to keep. What a DPA has to contain in either direction is set out in the canonical DPA guide; this article is only about the signing.
Who Inside Each Company Has Authority
The signatory is the legal entity, not the individual. The individual signs on the entity's behalf, and the entity named has to be the one that actually holds the relationship.
Three things go wrong here often enough to be worth checking. The wrong group entity gets named — the US parent signs when the contracting party is the UK subsidiary, or vice versa. The individual has no delegated authority, which is common when a DPA is routed to whoever happened to receive the questionnaire. And the entity named in the DPA does not match the entity on the master services agreement, which creates a genuine question about which contract governs what.
Practical rule: the DPA should be signed by the same entity that signed the underlying commercial agreement, by someone with authority to bind it. If your DPA is accepted through a self-serve flow, the flow should capture who accepted it and confirm they were authorised — which matters more than it sounds, because that record is the only evidence you will have.
Whose Paper Wins
Neither side has a legal right to insist on theirs. In practice it follows leverage, and the pattern is consistent: the larger party's template is used, and below a certain deal size the vendor's standard terms are accepted without negotiation.
For a small SaaS selling to enterprise, that means you will receive your customer's DPA and be asked to sign it. This is where the terms that hurt tend to appear — audit rights with short notice, deletion commitments on impossible timescales, sub-processor approval rights that require consent for each change rather than notice with a right to object, and liability positions inconsistent with the main agreement.
Two things make this manageable. Have your own DPA published and accessible so it is offered before theirs arrives, which resolves a surprising proportion of cases. And know which of your standard terms you can actually meet, because a negotiated commitment you cannot deliver is worse than one you refused. If the exchange started with a security review, the same principle applies as with the questionnaire itself — the document pack is easier to hand over than to reconstruct under time pressure.
Does It Actually Need A Signature?
Not in the sense most people mean. Article 28(9) requires the contract or other legal act to be in writing, including in electronic form. There is no requirement for a wet signature, and no requirement for a standalone document.
That means several forms are valid: a signed standalone DPA, a schedule to the master services agreement, terms incorporated by reference from a URL where the incorporation is clear and the customer has notice, and click-through acceptance in an account settings page. The last is how most self-serve SaaS handles it and it is entirely defensible when implemented properly.
What "properly" requires is that the terms were presented, the acceptance was a positive act, and you can evidence both later. A URL in a footer that nobody was directed to is not incorporation.
Two qualifications are worth carrying. National contract law still governs whether a party has actually agreed, and merely making a DPA visible is unlikely to be enough in most Member States — a positive act is needed. And the EDPB has recommended including signatures precisely so there is no difficulty demonstrating the contract is in force. Valid without a signature is not the same as easy to evidence without one. Where you do want a signed document — enterprise deals, procurement processes that require one, or simply because a countersigned PDF is easier to produce in a review — an e-signature service handles it, and DPA signing through Dropbox Sign is the kind of integration that turns this from a task into a link.
What To Record When It Is Signed
The signing is not the deliverable. The record is, because everything you will be asked afterwards is a question about the record.
Capture the entity on each side, the individual who signed and their role, the date, the version of the terms, whether it was a signature or an acceptance and by what mechanism, the sub-processor authorisation model and notice period, and where the executed copy lives. If transfer clauses were incorporated, note which instrument and which modules — that detail is the one most likely to be needed and least likely to have been written down.
Do the same in the other direction for every vendor DPA you accept, and keep the two registers in the same place. The question "who signed what, when, and which version" is asked in every serious vendor review, and it is far cheaper to answer from a register than from an inbox. The prior question of which vendors need a DPA at all determines how long that register needs to be.
Common Mistakes With DPA Signing
Signing the wrong entity. A group company that is not party to the commercial agreement signing the DPA creates a contract between parties with no underlying relationship. Match the entity to the master agreement every time.
Accepting a customer's DPA without reading the sub-processor clause. Per-change approval rights are common in enterprise templates and operationally severe. You cannot add a hosting region or swap an email provider without collecting consents you will not get promptly.
Treating a published DPA as executed. Publishing terms is an offer. Until the counterparty accepts them by a recorded positive act, nothing is in place, and "it is on our website" is not an answer to a due diligence question.
Losing the version. Vendors update their DPAs, sometimes materially. A register entry without a version and date cannot tell you what you agreed to, and re-deriving it after the fact is often impossible.
Letting whoever received the request sign it. DPAs routed through support or sales get signed by people with no authority to bind the company. It is not usually fatal, but it is exactly the defect a thorough reviewer finds.
FAQ
Can our customer refuse to sign a DPA and still use the product?
They can decline to sign yours, but the obligation under Article 28 falls on them as controller, so declining leaves them exposed rather than you. In practice, some customers ignore the DPA entirely. Making it available and recording that it was offered is the sensible position, and many providers make acceptance a condition of the account.
Is a click-through DPA legally valid?
Yes, where it is implemented properly. Article 28(9) requires writing including electronic form, not a signature. The terms must have been presented, accepted by a positive act, and both facts must be evidenced. A pre-ticked box or a link nobody was shown does not meet that. The EDPB nevertheless recommends signatures, so treat click-through as valid but harder to prove.
Do we need to re-sign when the DPA is updated?
It depends on the change mechanism in the existing agreement. Many DPAs allow updates on notice, in which case no re-signature is needed but the notice and effective date should be recorded. Material changes to sub-processing, transfers or liability usually warrant a fresh acceptance, and the safer course is to obtain one.
Who signs when a reseller or agency sits in the middle?
Follow the data rather than the invoice. If the reseller only bills and never touches personal data, your DPA is with the end customer. If the reseller administers the account and handles data on the customer's behalf, there are two relationships to paper and both need to be described, not one.
Closing Thought
The reason this question is asked so often is that it exposes something uncomfortable: most SaaS companies have a clear answer for the direction facing their customers and a vague one for the direction facing their vendors. The customer-facing DPA is polished, published and reviewed by a lawyer, because it appears in sales conversations. The vendor-facing side is a folder of PDFs and a few acceptances nobody recorded, because nobody sells to you. The second half is the one an auditor reads first.
Keeping both directions in one place, with versions and dates, is most of the work. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, with DPA signing through DocuSign and Dropbox Sign so the customer-facing side becomes a link rather than an email thread. It does not negotiate a customer's template for you or decide whether their audit clause is acceptable — those remain commercial judgements.
