Processor vs. Controller Role Map for Outreach Vendors

Decide controller vs. processor by mapping who chooses the means of processing, who sets purposes, and who exercises decision-making about personal data handling. Use this role map to assign contract clauses, audit rights, and operational owners so your outreach vendors are governed consistently and defensibly.

Decision boundary: means versus purpose

The core legal distinction hinges on who determines the purposes of processing (why data is used) and who determines the means (how it is done). If your organization sets both the purposes and the key means, you are a controller; if the vendor only acts on instructions about purpose and the controller sets the means, the vendor is a processor. Where a vendor chooses significant technical or operational means independently, they may be a joint controller or a controller for those activities. Be explicit about which choices count as 'means' in outreach: template selection, send cadence, segmentation logic, bounce handling, and data enrichment can each influence whether a vendor is making operational choices. Treat any vendor decision that has material influence on how personal data is collected, profiled, or disclosed as potential 'means' rather than a mere implementation detail.

Evidence limits and how to gather it

Document the vendor’s operational autonomy using configuration records, runbooks, and historic logs that show who set defaults and who changed them. Evidence should answer: who configured segmentation rules; who enabled automated AI personalization; who controlled delivery throttles; and who initiated data enrichment jobs. Where vendor marketing or contracts are silent, rely on system traces and change logs. Understand the limits of evidence: provider documentation may not reflect current custom settings and marketing claims are not determinative of legal role. When evidence is ambiguous, treat the relationship as potentially joint or controller and increase contractual protections and governance until clarified.

Practical sequence to determine role

Step 1: Map functional tasks (list collection, segmentation, template design, sending, suppression, tracking, enrichment). For each task note who decides the purpose and who decides the method. Step 2: Collect objective artifacts (UI permission records, API keys, change logs, onboarding emails, contract clauses). Step 3: Apply the decision boundary: if vendor decides both purpose and means for any task, treat them as a controller for that task; if vendor only acts on documented instructions, treat them as processor. Step 4: If mixed responsibilities exist across tasks, document per-task roles and require either a joint controller agreement or split contracts and appropriate DPAs. Record stop conditions — e.g., vendor begins auto-optimizations without documented instruction — that trigger reclassification and contractual escalation.

Operational controls and contract implications

If the vendor is a processor, require a Data Processing Agreement (DPA) that limits scope, prohibits independent repurposing, requires subprocessors list, and sets audit and deletion obligations. If the vendor is a controller or joint controller for certain activities, negotiate a controller–controller (or joint controller) agreement that allocates responsibilities for data subject rights, lawful basis, and breach notifications. Specify operational controls: who must approve templates, who can alter segmentation logic, how consent signals are communicated, and which logs must be retained. Prefer explicit approval gates for any automated optimization features and require the vendor to surface decisions that materially affect recipients so you can evidence control or instruction.

Examples (labeled) to illustrate edge cases

Example 1 — Processor: A vendor sends messages using lists and templates you supply, follows send schedules you configure, and performs delivery using fixed throttles you set; they do not independently enrich or profile. This maps to a processor role for sending. Example 2 — Joint controller/controller: A vendor runs proprietary audience scoring that they design and use to decide sends without your instruction; they also collect consent via their widget. For those scoring and collection activities they act as a controller or joint controller. Treat other activities separately and document accordingly.

Practical checklist

• Inventory outreach tasks and label who sets purpose and who sets means for each task.
• Request and archive configuration snapshots, change logs, and API permission records from the vendor.
• Identify any vendor features that autonomously modify segmentation, templates, or cadence; require explicit opt-in for autonomous optimization.
• Match role findings to contract type: DPA for processor activities; controller agreements for controller/joint controller activities.
• Mandate subprocessors list, audit rights, and deletion/return procedures in the DPA.
• Define operational approval gates (templates, segments, enrichment feeds) and responsible internal owners.
• Set monitoring triggers (unexpected sends, new enrichment source, sudden permission changes) that escalate to legal/compliance.
• Record stop conditions that switch a task’s role classification and require immediate contractual/operational review.
• Link role map outputs to ROPA, vendor review, and your DPA checklist for ongoing governance.

Where RepMail fits

Use this guide as an operational checklist and diagnostic when reviewing or onboarding outreach vendors. Map task-level roles into your ROPA, vendor review, and DPA checklist so outreach governance, audit rights, and escalation paths are captured in workflows. Do not assume provider claims determine legal status; rely on configuration evidence and documented instructions when operationalizing outbound controls.

Continue with Cold Email Compliance Recordkeeping: What to Log for the next step in the workflow.

Related RepMail guides

• Adequacy Decision vs. Safeguard: Cross-Border Routing Choice
• B2B Corporate Subscriber vs. Individual Address: PECR Routing

Sources