salesforce-marketing-consent-review-skill

Salesforce Marketing Consent Review Skill

Purpose

This skill reviews marketing data flows for consent capture, lawful basis, purpose limitation, preference center coverage, suppression list integrity, subscriber-key collision risk, deliverability authentication, and unsubscribe link integrity. It exists because marketing data flows — particularly in Marketing Cloud , Account Engagement , and Data Cloud — frequently cross jurisdictions and involve regulated personal data subject to GDPR, CCPA, CASL, and other consent-based frameworks. It does not access live marketing accounts or authorize changes.

When to use

• A marketing data flow is being designed or reviewed for compliance.
• A consent model is being assessed for a new campaign or channel.
• A deliverability issue may be related to authentication configuration.
• A preference center redesign needs consent-model review.
• A subscriber-key migration or Data Cloud integration is planned.

When not to use

• General Salesforce integration (no marketing data) — use salesforce-integration-review-skill.
• Live Marketing Cloud change deployment — use salesforce-live-change-approval-protocol.
• Data exposure event response — use salesforce-data-exposure-escalation-protocol.
• Full org assessment — use salesforce-org-assessment-skill.

Minimum payload (required inputs)

• Description of the marketing data flow: source systems, destination (Marketing

Cloud, Account Engagement, Data Cloud), data categories involved.

• Jurisdiction(s) where subscribers are located (or note that it is unknown).
• Consent model description: how consent is captured, what lawful basis is claimed.
• Preference center description (or note that it is absent).
• Sending domain(s) (sanitized, no live API keys or credentials).

Workflow

1. Consent capture review

• Identify where consent is captured: web form, API, import, point of sale.
• Flag: consent captured without a clear affirmative action (pre-ticked boxes,

bundled consent).

• Flag: consent captured without a timestamp and source record (not auditable).
• Flag: consent captured via a third-party list import without documented

lawful basis for the jurisdiction.

• Flag: re-permission campaigns not used when consent records are > configurable

age threshold.

2. Lawful basis assessment

• Identify the claimed lawful basis per jurisdiction:
• GDPR (EU/EEA): consent, legitimate interest (with documented LIA),

contract, legal obligation.

• CCPA (California): right to opt-out of sale; identify whether the

flow constitutes a "sale" under CCPA.

• CASL (Canada): express vs implied consent; flag implied consent without

an expiry tracking mechanism.

• Other jurisdictions: flag if jurisdiction is identified but lawful basis

is not documented.

• Flag: single lawful basis asserted globally when multi-jurisdiction subscribers

require jurisdiction-specific bases.

• Flag: legitimate interest asserted without a documented Legitimate Interest

Assessment (LIA).

3. Purpose limitation

• Verify that data collected for one purpose is not used for a materially

different marketing purpose without a separate consent.

• Flag: contact data collected in a Service Cloud context being synced to

Marketing Cloud for promotional campaigns without a separate consent capture.

• Flag: Data Cloud segments built

from data collected under a different purpose than marketing.

4. Preference center coverage

• Verify that a preference center exists and covers all active channels

(email, SMS, push, direct mail).

• Flag: preference center that does not honor opt-outs within a documented

processing time (e.g., 10 business days).

• Flag: preference center that does not propagate suppression to all active

sending platforms (Marketing Cloud, Account Engagement, and any third-party senders).

• Flag: preference center that requires an account login to opt out (barrier to

opt-out is a compliance risk).

5. Suppression list integrity

• Verify that suppression lists (global unsubscribes, do-not-contact lists,

hard bounces) are applied across all sending platforms.

• Flag: suppression list sync with > configurable delay (stale suppression

can result in sending to opted-out subscribers).

• Flag: suppression list managed manually without automated sync to all platforms.
• Flag: hard bounces not suppressed (can damage sender reputation and may

violate CAN-SPAM/CASL).

6. Subscriber-key design and collision risk

• Review the subscriber key design in Marketing Cloud

.

• Flag: subscriber keys using email addresses as the key (email changes cause

key collisions and duplicate subscriber records).

• Flag: subscriber key not synchronized with the CRM contact ID (leads to

orphaned subscriber records).

• Flag: subscriber key strategy not defined before Data Cloud integration

(can cause identity resolution failures).

7. Deliverability authentication

• Review the sending domain configuration:
• SPF: verify that an SPF record exists for the sending domain and includes

Marketing Cloud sending IPs.

• DKIM: verify that DKIM signing is configured for the sending domain.
• DMARC: verify that a DMARC policy exists; flag if policy is p=none

(monitoring only, no enforcement).

• Flag: sending from a shared IP pool without dedicated IP warm-up plan.
• Flag: DMARC policy p=reject or p=quarantine without monitoring in place

(can result in false positives if misconfigured).

8. Unsubscribe link integrity

• Verify that all email sends include a functional unsubscribe link.
• Flag: unsubscribe link that requires authentication or account creation.
• Flag: unsubscribe that routes to a preference center with a long opt-out

process (more than 2 clicks).

• Flag: transactional email templates where an unsubscribe link is absent but

the email contains promotional content.

• Flag: one-click unsubscribe not implemented where List-Unsubscribe header

is expected by receiving mail providers.

Evidence requirements

• Sanitized marketing data flow description; no credentials, API keys, or

customer data.

• Jurisdiction(s) identified or noted as unknown.
• Consent model description; if absent, flag as a high-risk unknown.

Output format

marketing_consent_review_findings:
  consent_capture:
    - finding: [description]
      severity: Critical | High | Medium | Low
      jurisdiction: [applicable, or "all"]
      recommendation: [brief]
  lawful_basis: [same structure]
  purpose_limitation: [same structure]
  preference_center: [same structure]
  suppression_list: [same structure]
  subscriber_key_design: [same structure]
  deliverability_authentication: [same structure]
  unsubscribe_integrity: [same structure]

summary:
  total_findings: [count]
  critical_count: [count]
  high_count: [count]
escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
open_questions_for_counsel: [list — do not answer; require legal determination]
assumptions: [list]
missing_evidence: [what would improve the review]

Redaction rules

• Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
• Sanitize org IDs, user IDs (replace with placeholders) before sharing in outputs.
• Subscriber data, email addresses, and contact records must not appear in outputs.

Privilege / data handling rules

• This review may surface findings that have regulatory notification implications.

Flag and route to privacy counsel before any public statement.

• Lawful basis assessments are not legal conclusions; all findings require

verification by qualified privacy counsel.

• Regulated-data marketing flows (health, financial) escalate to compliance review.

Handoff rules

• Hands off to: salesforce-data-exposure-escalation-protocol (if consent violation

constitutes a data exposure event), salesforce-integration-review-skill (if integration design gaps underlie consent failures), salesfo