Rules and ethics
Part of Six separate legal questions to answer before marketing automation sends anything
Marketing automation data protection: how objections travel
Marketing automation data protection in the UK: purposes, lawful bases, transparency, objections that must reach every sending system and every imported list.
For an organisation operating in England, document the source, purpose, fields, inferences, recipients, retention and deletion route before configuring a journey. Then assess your marketing automation data protection duties under UK GDPR and any separate PECR requirement.
This is general information, not a DPIA and not advice on a particular data set. Take advice from a UK data-protection lawyer or a qualified privacy professional on the current law, guidance and scope before you rely on it.
The Information Commissioner's Office enforces UK GDPR and PECR across the UK, including England. It can investigate complaints and issue warnings, reprimands and enforcement notices.
For UK GDPR breaches the ICO can fine an organisation up to £17.5 million or 4% of annual global turnover, whichever is higher. The ICO enforces PECR alongside UK GDPR, and since the Data (Use and Access) Act 2025 changes took effect in early 2026 the maximum PECR fine matches the UK GDPR level.
What to take away
- Map data flows and document purposes before configuring a marketing automation journey.
- Choose and record a lawful basis for each purpose, not for the platform.
- Ensure objections and withdrawals reach every sending system and audience sync.
- Check PECR for tracking technologies and international transfers separately from UK GDPR.
Give each operation a purpose
Avoid a single purpose called "marketing". Collecting a form submission, enriching a record, predicting interest, selecting a message, suppressing an objector and measuring a response are different operations. Write the purpose and the minimum data needed for each one.
The ICO's data-protection-by-design guidance says privacy measures should be built into processing from design through the lifecycle, and default use should be limited to what is necessary for each purpose. The Data (Use and Access) Act 2025 amended parts of the UK data-protection framework, and the ICO has been updating its guidance to match.
Decide and record the lawful basis
The basis belongs to the purpose, not to the platform. The ICO's lawful-basis guidance identifies seven bases (the list now includes recognised legitimate interests, added by the Data (Use and Access) Act 2025) and says the choice must be made and documented before processing begins. Where an organisation considers consent or legitimate interests, it should record why that basis fits the actual relationship, necessity and impact.
Do not confuse this with PECR. The lawful basis addresses processing personal information. PECR may separately require consent or satisfaction of a soft opt-in for a channel. A valid basis does not itself authorise an email, text or tracking pixel.
Explain the real workflow
Privacy information should describe sources, uses, recipients and retention in language a person can understand. It should cover profiling or automated decisions where relevant and explain available rights. The ICO's right-to-be-informed material says organisations must regularly review and update their privacy information.
Compare the notice with the live configuration. If a new enrichment provider, model, destination or reuse is absent, hold the change. Do not repair the mismatch solely by making the notice broader.
Make objections and withdrawal travel
A person can object through more than an unsubscribe link: support tickets, account conversations and direct replies may express the same choice. Under Article 21 of the UK GDPR, the right to object to processing for direct marketing is absolute, and the ICO's guidance on the right to object says the same. Withdrawing consent under Article 7(3) must be as easy as giving it, and both an objection and a withdrawal are recorded the same way in the workflow.
Test how a request reaches every sending system, audience sync and imported list, and use the migration checklist when you move consent and suppression data between platforms. Retain only the information needed to enforce suppression, with its own documented purpose and access control.
Each platform keeps its own view of who has opted out, and an objection is only enforced when every one of those views agrees. In HubSpot it is the contact's subscription status and global unsubscribe setting; in Salesforce Marketing Cloud it is the subscriber status on the All Subscribers list and on any publication list; in Braze it is the subscription group; in Mailchimp it is the audience status and the suppression list.
Send the suppression over the same sync or connector that carries the contact record, and check that it carries the opt-out flag, not profile fields alone.
Worked example: a person submits a form on the site through a HubSpot form. The workflow enriches the record with job title and company from a data-enrichment provider such as Cognism or ZoomInfo, then syncs the enriched record to a Salesforce Marketing Cloud journey. The journey sends a welcome email through that platform.
The person replies and asks to stop receiving marketing. The reply should create an objection record and add the contact to the suppression list. The suppression must reach the HubSpot contact record (through your CRM integration), the enrichment provider's stored copy, the Salesforce Marketing Cloud journey and every imported list before the next send.
Propagation test: re-import the objector's record into the source list and trigger a send. Check that the suppression holds in the CRM, the enrichment provider and each sending platform, whether that is Salesforce Marketing Cloud, Braze or Mailchimp.
Common failure modes: an import that recreates the contact without the suppression flag, a sync that updates only the sending platform, and a suppression list applied after the send is queued.
An example field mapping for the opt-out flag
Decide which system is the source of truth, then map its opt-out to the matching field elsewhere. In this illustration the CRM holds the master record:
- HubSpot:the contact property "Unsubscribed from all email" (internal name hs_email_optout) is set to true.
- Salesforce CRM:the standard field HasOptedOutOfEmail on the Lead and the Contact is set to true.
- Salesforce Marketing Cloud:the subscriber status becomes Unsubscribed on the All Subscribers list. If you use Marketing Cloud Connect, configure which direction the opt-out syncs, and test it.
- Mailchimp:the member status becomes unsubscribed, through the API or the connector you use.
- Braze:the user's email subscription state becomes unsubscribed, and the user is removed from the relevant subscription groups.
- Enrichment provider:add the contact to its suppression or do-not-contact list, by API or portal as the contract allows.
If you use the native HubSpot and Salesforce integration, check that the field mapping pairs the first two items. Where no native connector exists, a tool such as Zapier or Make can carry the flag, but then you must monitor failed runs. Set a retry for failures and run a daily reconciliation that compares the number of opted-out contacts in each system. Treat any difference as an incident to investigate before the next send.
When you review platforms, run this propagation test as a pass or fail criterion. A platform that cannot receive or send the opt-out flag by a connector or API is a poor fit for any multi-system set-up.
Check tracking and overseas access separately
Pixels, scripts and similar tools may engage PECR's storage-and-access rules even when the same journey already has a UK GDPR basis. The ICO finalised its technology guidance in April 2026. Inventory each technology and purpose, then document the relevant exception or consent route.
A supplier outside the UK, or access by a separate overseas organisation, may create a restricted transfer. The ICO's international-transfer guidance explains its three-step test and was updated in January 2026. Legal review should consider the real legal entities and access path, not a sales label such as "UK region".
Hold the release when facts change
Guidance and legislation change. Record the version of each ICO page or other source you relied on, and recheck it before you depend on a step here.
Trace one contact through the system, marking every point where information is copied, inferred, exposed or deleted. Any change to purpose, source, field, inference, recipient, retention, tracking or transfer is a trigger to pause the journey.
Before you act
- Document source, purpose, fields, inferences, recipients, retention and deletion route.
- Write the purpose and minimum data needed for each operation.
- Decide and record the lawful basis before processing begins.
- Compare privacy notice with live configuration and hold changes if mismatched.
- Test how objections and withdrawals reach every system.
- Inventory each tracking technology and document consent or exception.
- Pause the journey when purpose, source, field, inference, recipient, retention, tracking or transfer changes.
Common questions
What should be documented before configuring a marketing automation journey?
Document the source, purpose, fields, inferences, recipients, retention and deletion route for a person's information. Then assess UK GDPR duties and any separate PECR requirement. This mapping ensures data protection is built in from the start.
How should objections and withdrawals be handled in a marketing automation workflow?
Support tickets, account conversations and direct replies may express an objection. Test how a request reaches every sending system, audience sync and imported list. Retain only information needed to enforce suppression, with its own documented purpose and access control.
Why is PECR relevant even when a lawful basis exists for processing?
PECR may separately require consent or satisfaction of a soft opt-in for a channel. A valid lawful basis does not itself authorise an email, text or tracking pixel.
