Email Signature Tools and GDPR: What Your DPO Needs to Know (2026)
TL;DR: Most email signature management tools work by routing your organisation’s outbound email through their own cloud infrastructure. Under UK GDPR, that makes them a data processor — and you need a written Data Processing Agreement before any personal data is processed. Many organisations have signed up for these tools, agreed to a DPA they haven’t read carefully, and don’t fully understand what they’ve consented to. This article explains the obligation clearly, what a proper DPA needs to cover, and what questions to ask any signature vendor before committing.
Why email signature management is a GDPR consideration at all
Most GDPR conversations in IT focus on databases, CRM systems, HR platforms — the obvious places where personal data lives. Email signature management rarely comes up. It should.
The reason it gets overlooked is architectural. When IT teams evaluate email signature tools, they’re thinking about features: does it sync with Azure AD, can marketing set up a campaign banner, does it work on Mac. The data processing question — where does email go between leaving Outlook and reaching the recipient — isn’t usually on the evaluation checklist.
It should be. Because the answer, for the majority of tools in the category, is: it passes through the signature vendor’s cloud server.
That routing is not incidental. It is the mechanism by which the signature is appended. The email travels from your Exchange Online tenant, out to the vendor’s infrastructure, the signature HTML is added to the message, and then it’s forwarded on to the recipient. The vendor’s server sees the email body, the recipient addresses, any attachments, the subject line. All of it, for every outbound email your organisation sends.
That is, unambiguously, processing of personal data on your behalf. It triggers Article 28 of the UK GDPR.
What Article 28 requires
Article 28 of the UK GDPR sets out the rules for using data processors — organisations that process personal data on your behalf. The core obligation is straightforward: you must have a written contract with the processor that includes specific terms.
The ICO’s guidance on what must be included in a controller-processor contract is comprehensive, but the key requirements are:
The processor must only process data on your documented instructions. They cannot use your organisation’s email data for their own purposes — analytics, product development, training, or anything else — unless you have explicitly authorised it. Your DPA should state clearly what the processor is and is not permitted to do with the data.
The processor must implement appropriate technical and organisational security measures. This is not just a box-ticking exercise. You are responsible for assessing whether their security measures are sufficient for the risk involved. An email signature vendor processing your entire outbound email stream represents a material risk surface.
Sub-processors must be disclosed and authorised. If the vendor uses sub-processors — cloud hosting providers, CDN services, analytics platforms — those must be listed, and you must have given either specific or general written authorisation for them. Changes to the sub-processor list require notification and the right to object. Check the sub-processor list in any DPA carefully; it is often longer than organisations expect.
The processor must assist with breach notification. If the vendor experiences a breach involving your data, they must notify you without undue delay. Your organisation then has 72 hours to notify the ICO if the breach is likely to result in a risk to individuals’ rights and freedoms. A DPA that doesn’t include clear breach notification obligations is non-compliant.
Deletion or return of data on termination. When you end the contract, the processor must either delete or return all personal data, and delete existing copies unless UK law requires retention. Your DPA should specify the timelines and mechanism for this.
Audit rights. You have the right to audit your processor’s compliance. In practice, most organisations never exercise this right, but it must exist in the contract. Some vendors satisfy this requirement through certification schemes (ISO 27001, SOC 2) rather than direct audit access — check what your DPA offers.
The ICO’s guidance on controller-processor contracts is available at ico.org.uk and is the authoritative reference for UK organisations. Note that following the Data (Use and Access) Act 2025 coming into law in June 2025, ICO guidance in this area is under active review — check for updates before finalising any new DPA.
What data does an email signature tool actually process?
This varies by architecture, and the distinction matters more than most evaluations recognise.
Server-side tools — the majority of the market, including the largest vendors — process your outbound email after it leaves your Exchange Online tenant. Depending on the vendor’s technical implementation, this may include:
- The full email body (text and HTML)
- Attachments
- Recipient names and email addresses (To, Cc, Bcc)
- The subject line
- Sender identity
- Send timestamp and metadata
This is a broad data set. For a professional services firm, it includes client correspondence. For a financial services organisation, it may include communications that are subject to additional regulatory record-keeping requirements. For a healthcare organisation, it could include communications that contain sensitive personal data.
The DPA you sign with a server-side vendor is not a formality. It is a substantive legal agreement about who can do what with a significant volume of your organisation’s personal data.
Add-in-based tools operate differently. In this architectural model, the signature is injected at compose time by an Outlook add-in running inside the Microsoft 365 environment. The email is never routed through the vendor’s server. The vendor’s infrastructure receives only what is needed to deliver the signature — typically a request for the correct pre-rendered HTML signature file for a given user, and optionally an impression log (sender identity, timestamp, template used). The email body, recipient data, and attachments are never transmitted to the vendor.
The data processing obligations are substantially different as a result. The DPA with an add-in-based vendor covers profile data (the information used to personalise the signature — name, title, contact details) and any analytics data collected. It does not cover email content, because email content never reaches the vendor’s infrastructure.
For a detailed explanation of the two architectural approaches and their data processing implications, see Email Signature Management for Microsoft 365: Server-Side vs Add-In — What’s the Difference?.
The questions to ask your email signature vendor
Whether you’re evaluating a new tool or reviewing an existing contract, these are the questions that matter from a GDPR perspective.
Does email content pass through your infrastructure? Ask directly. The answer should be unambiguous. If the vendor is server-side, email passes through their servers. If they use an add-in model, it does not. Some vendors offer both deployment modes — clarify which mode you are using and what data each mode touches.
Do you have a standard DPA available? Any reputable vendor should have a DPA ready to provide before you start processing data. If a vendor cannot produce a DPA, or characterises it as optional, that is a significant red flag. Under UK GDPR, processing personal data without an Article 28-compliant contract in place is a breach — by both parties.
What is your full sub-processor list? Ask for it. The list should include cloud hosting providers, CDN services, analytics platforms, and any other third parties that may have access to data processed on your behalf. For server-side tools, this list often includes US-based cloud providers, which may raise additional considerations around international data transfers under the UK GDPR’s transfer provisions.
Where is data stored geographically? For UK and EU organisations, data residency matters. If a server-side vendor is routing your email through US-based infrastructure, that is an international transfer under UK GDPR and requires either an adequacy decision, standard contractual clauses, or another valid transfer mechanism. The UK-US data bridge (the UK Extension to the EU-US Data Privacy Framework) provides a mechanism for transfers to certified US organisations — but you need to verify the vendor is certified and that the mechanism is documented in the DPA.
What are your breach notification timelines? The ICO requires notification within 72 hours of becoming aware of a breach that poses a risk to individuals. Your DPA must obligate the vendor to notify you promptly enough to meet that deadline. Ask specifically: what is the contractual notification timeline, and what is the practical process?
What happens to our data when we cancel? Deletion timelines should be specified in the DPA. Ask what is deleted, when, and how you receive confirmation. For server-side tools where email content has been processed, this question covers a more significant data set than it does for add-in tools.
Do you have ISO 27001 or equivalent certification? Certification does not substitute for a proper DPA, but it is evidence of the technical and organisational measures required by Article 28(1). UK public sector and regulated sector buyers in particular should verify the certification status of any processor.
What about existing contracts?
If your organisation is already using an email signature management tool and hasn’t reviewed the DPA, now is a reasonable time to do so. The questions above apply to existing relationships, not just new ones. Under UK GDPR, the obligation to have a compliant contract with processors is ongoing — it doesn’t expire after the initial signup.
The most common gap we see in existing deployments is not the absence of a DPA — most vendors include one in their standard terms — but the absence of a meaningful review. The DPA was accepted during signup, possibly as a checkbox, and the sub-processor list and data processing scope have never been examined.
Three things are worth checking in any existing DPA:
The sub-processor list. Has it changed since you signed? Most DPAs include a right to object to new sub-processors, with a notification mechanism — check whether you’ve been notified of changes and whether your agreement reflects the current list.
Data residency. Where is data stored and processed? Has this changed? Several vendors have updated their infrastructure or added cloud regions since their original DPAs were issued.
Scope of processing. Does the DPA accurately reflect what data the tool is processing? If you’ve added users, integrated with new systems, or expanded usage since the original DPA was signed, the scope may have changed.
Is a DPA enough?
A DPA is necessary but not sufficient. Article 28 is one part of the UK GDPR framework. Before deploying any data processor, controllers should also consider:
Legitimate interest or another lawful basis. Processing personal data through a third-party processor requires a lawful basis under Article 6 (and, where applicable, Article 9 for special category data). For email signature management, the most common basis is legitimate interests — the organisation has a legitimate interest in consistent, legally compliant email signatures. A brief legitimate interests assessment is good practice and supports accountability obligations.
Records of processing activities. Under Article 30, most organisations must maintain records of their processing activities. Email signature management — particularly server-side — should appear in these records as a processing activity, with the vendor listed as a processor.
Data Protection Impact Assessment. A DPIA is required where processing is likely to result in a high risk to individuals. Server-side email routing is a broad processing activity covering a large volume of business correspondence — organisations in regulated sectors, or those handling sensitive personal data in email, should consider whether a DPIA is warranted.
A note on the add-in model and GDPR
To be transparent about the position this article comes from: SigHQ uses an add-in-first architecture, meaning email content never leaves Microsoft’s infrastructure. Our DPA covers profile data and impression analytics only — not email content.
We think this architecture is the right approach from a privacy perspective, and we think the market hasn’t scrutinised the data processing implications of server-side routing carefully enough. But we also recognise that server-side tools have a DPA in place, that many organisations have reviewed and accepted that DPA with full awareness of what it covers, and that for some organisations the tradeoffs favour server-side deployment.
The right question is not “does a DPA exist?” — most vendors have one. It is “have you read it, do you understand what it authorises, and is that consistent with your obligations to your own data subjects?”
For more on how the two architectures differ in terms of data handling, see Email Signature Tools and GDPR: Server-Side vs Add-In Architecture Explained. For the specific UK legal requirements around email signature content, see Email Signature Compliance for UK Businesses: What the Law Actually Requires.
Checklist: GDPR compliance for email signature management
Use this before deploying a new tool or reviewing an existing one.
- Confirm whether the tool routes email through third-party servers (server-side) or injects signatures within the Microsoft/Google environment (add-in)
- Obtain and review the vendor’s DPA before processing begins
- Check the sub-processor list — verify all sub-processors, their locations, and the transfer mechanisms in place for any outside the UK
- Confirm breach notification obligations and timelines in the DPA
- Confirm data deletion obligations on termination, including timelines
- Record the processing activity in your Article 30 records
- Consider whether a legitimate interests assessment is needed for the processing
- Consider whether a DPIA is required, particularly for regulated sector organisations or those handling sensitive personal data in email
- For existing deployments: review the DPA against the current sub-processor list and current scope of processing
This article is for informational purposes and does not constitute legal advice. UK GDPR obligations are fact-specific — organisations with complex data processing arrangements or operating in regulated sectors should take specialist legal advice. ICO guidance referenced in this article is available at ico.org.uk. Following the Data (Use and Access) Act 2025, some ICO guidance is under active review — verify current guidance before making compliance decisions.