How to Get an SFMC Audience-Activation Vendor Through Security Review

Security reviews for marketing technology are slow, frustrating, and frequently derailed by a basic mismatch: the security team is asking questions designed for a SaaS platform that stores and processes data, and the vendor is a tool that was never designed to store data at all. Both sides are using frameworks that do not quite fit the thing they are evaluating.

This post is written for both audiences. If you are a marketer trying to get an audience-activation tool approved, you need to understand what the security team is actually trying to learn — not just what forms they are asking you to fill out. If you are a security analyst evaluating an ad-tech or audience-activation vendor for a Salesforce Marketing Cloud environment, the standard vendor questionnaire is a starting point, not an end point, and architecture matters more than certification status for tools in this category.

Start with what the Salesforce AppExchange security review actually means, then work through the questions that determine whether a vendor's architecture is sound.

What the AppExchange Security Review Actually Tells You

Salesforce requires every app listed on the AppExchange to pass a security review before it can be published. The review covers the application's code and architecture against Salesforce security standards — authentication, API usage, data handling within the Salesforce platform boundary, and a range of OWASP-aligned vulnerability checks.

For a security team evaluating an AppExchange-listed tool, this is a meaningful signal. It means a credentialed third party (Salesforce and its security partners) has reviewed the application and found it meets a defined standard. That is not nothing, and it is considerably more than what you get from a custom integration or a tool built by an agency that had access to a sandbox.

It is also not sufficient on its own. The AppExchange review does not evaluate what the vendor does outside the Salesforce platform boundary — how they handle data in transit to third-party ad platforms, what infrastructure they operate independently, what their incident response process looks like, or who their sub-processors are. These are legitimate questions, and a responsible security team will ask them regardless of AppExchange listing status.

The useful frame: AppExchange listing lowers the floor of concern around the in-platform behavior of the application. It does not answer the full set of questions a thorough security review requires.

The Questions That Actually Matter

What follows is a structured set of questions for evaluating an audience-activation vendor — one that connects your Marketing Cloud data to ad platforms. Each question includes what a strong answer looks like.

1. Show us a data flow diagram. Where does customer data go, and when?

This is the first question and the most important. If a vendor cannot produce a clear, specific data flow diagram on request, that is itself an answer.

The diagram should show: the source of data (Data Extension, Journey Builder, etc.), any transformation steps (hashing, formatting), the path to the ad platform, and any intermediate storage — vendor servers, cloud storage buckets, message queues. It should distinguish between data that passes through the vendor's infrastructure and data that is processed entirely within the customer's own environment.

What a strong answer looks like: A diagram is produced promptly. It clearly shows where hashing occurs relative to the customer's environment boundary. Every node in the data flow is identified with the hosting environment and the retention period for any data that persists at that node.

2. Is any customer data stored by the vendor? If yes: where, for how long, under what access controls?

This is the question that most differentiates tools in this category. Some audience-activation vendors maintain a copy of your customer data — a replicated or cached version of the audiences you activate — on their own infrastructure. Others are designed as pass-through tools where data is processed and transmitted but never retained.

The distinction matters enormously for the attack surface. A vendor that retains a copy of your customer audience data has created an additional target: their infrastructure now holds data that, if breached, represents a breach of your customer data. A vendor that stores nothing has a fundamentally smaller attack surface for the specific question of customer data exposure.

What a strong answer looks like: "No customer data is stored on our infrastructure. Data is processed [location] and transmitted to the destination platform. The only persistent data in our systems is [configuration data, audience metadata, sync logs] — not customer identifiers." The vendor should be able to support this with their data flow documentation.

3. Where does hashing occur?

Hashing before transmission to ad platforms is standard practice — it means the platform receives a hashed identifier rather than a cleartext email address. But where the hashing happens is not a minor implementation detail.

If hashing occurs on the vendor's servers, cleartext PII traveled from your environment to the vendor's infrastructure before being hashed. The vendor's servers received your customers' cleartext email addresses. If hashing occurs inside your own environment — inside your own Marketing Cloud instance — cleartext identifiers never leave your governed systems. Only hashed values are transmitted.

This is the architectural question that most directly determines the data exposure profile of the tool. "We hash everything" is not a sufficient answer. "Where does the hashing happen, relative to our environment?" is the follow-up that matters.

What a strong answer looks like: Hashing occurs inside the customer's own environment, prior to any data leaving the customer's systems. The vendor's infrastructure never receives cleartext identifiers.

4. How are ad platform connections authenticated, and how is access revoked?

Ad platform connections are privileged: they grant the ability to create and update audiences on behalf of your advertising accounts. The authentication model for these connections determines how much control your IT and security teams have over them.

OAuth 2.0 is the standard — it allows token-based authentication without requiring the vendor to store your ad platform credentials, and it allows revocation at any time. The more important operational question is: when an employee who set up a connection leaves the organization, or when a contract with a vendor ends, can your IT team revoke access immediately and completely? Or does revocation require the vendor to take action on your behalf?

What a strong answer looks like: Connections use OAuth 2.0 and are managed under the customer's IT team's control. Revocation can be performed by the customer directly, without vendor involvement, and takes effect immediately. The vendor does not hold long-lived credentials to the customer's ad accounts.

5. Who are your sub-processors, and what data do they receive?

A vendor's security posture is only as strong as the third parties they rely on for infrastructure and operations. A vendor that stores nothing may still route data through a cloud infrastructure provider, a monitoring platform, or a data pipeline tool — each of which is a potential exposure point and a subject for your security review.

The answer to this question should be a specific list, not a reference to a generic "third parties may include" clause in a terms of service. Each sub-processor should be identified with the category of data they receive and their own security certifications or assessments.

What a strong answer looks like: A specific, current sub-processor list with the data category received by each. If the vendor stores no customer data, most sub-processors will only receive configuration, log, or telemetry data — which should be stated explicitly.

6. What does your audit log capture, and who can access it?

In the context of audience activation, audit logging means: for every audience sync, there is a record of what ran, when it ran, what source it drew from, and what destination it sent to. This is the data that answers the compliance question — "What did we send to Meta in March?" — without requiring a forensic reconstruction from email attachments and Slack history.

The important sub-question is who controls that log. If the audit log lives only in the vendor's systems, your access to it depends on the vendor's cooperation and their data retention policy. If the log is generated inside your own environment, you own it.

What a strong answer looks like: Detailed sync logs are generated per run, retained for a defined period, and accessible within the customer's environment. Logs include: timestamp, audience identifier, source criteria, destination platform, and sync status. The customer does not need to contact the vendor to access their own sync history.

7. What is your breach notification process and timeline?

This question is often asked and often answered with a reference to a policy document. Push for specifics: How is a breach detected? Who is notified, by what mechanism, within what timeframe? Is notification contractual?

What a strong answer looks like: A documented incident response process with specific notification timelines (commonly 72 hours under GDPR frameworks), a defined escalation path, and a clear statement of what constitutes a notifiable incident under the vendor's assessment.

On Certifications: Useful, Not Sufficient, Not Required

SOC 2 Type II, ISO 27001, and similar certifications are useful evidence of security maturity. They represent a sustained, third-party-audited security program. If a vendor has them, they provide meaningful assurance about controls that are difficult to evaluate in a questionnaire.

That said, certifications are not a substitute for architecture questions — particularly for tools in the audience-activation category. A vendor with SOC 2 Type II that stores a copy of your customer data has a larger attack surface than a vendor with no certification that stores nothing. The certification addresses the quality of controls over what is stored; it does not address whether something should be stored in the first place.

Young or recently-launched vendors may not yet have completed a SOC 2 audit. This is not automatically disqualifying. A SOC 2 Type II audit takes sustained time and investment; many legitimate, well-architected tools are on the certification roadmap but have not yet completed the process. The relevant questions are: Is certification on the roadmap, with a specific timeline? Can the vendor provide a data-flow diagram and security documentation equivalent to what would be required for a Type I report? Has the vendor's AppExchange application passed the Salesforce security review?

Architecture — where data flows, where it is stored, where hashing happens, who controls access — is more directly informative about the actual risk profile of a tool in this category than a certification badge alone.

How Marketers Can Cut Weeks Off the Procurement Timeline

Security reviews for martech tools take weeks, sometimes months, not because the questions are hard but because the review process is typically reactive: the security team receives a tool recommendation from the marketing team, sends a questionnaire, waits for responses, asks follow-up questions, waits again. Each cycle adds time.

Most of that latency is eliminable if the marketer comes to the first meeting prepared.

Bring the data-flow diagram. Obtain it from the vendor before the first security team meeting. If the vendor cannot produce one quickly, that is already relevant information. If they can, reviewing it in the first meeting eliminates the most common first-cycle delay.

Pre-answer the question list. The questions in this guide are representative of what a thorough security review covers. Work through them with the vendor's security or technical team before engaging your internal security analyst. Have written answers — not just verbal assurances — ready to share.

Know the AppExchange status. If the tool is AppExchange-listed, confirm this before the first security meeting and be prepared to explain what the AppExchange review covers (and what it does not). Security teams who are unfamiliar with the AppExchange review process will spend time investigating something that is already resolved.

Identify the data residency question early. In many organizations, the primary concern is data residency — whether customer data leaves a specific region or jurisdiction. If the tool stores nothing, this concern is substantially reduced. If the tool processes data through cloud infrastructure, know the region configuration and have it in writing.

Request security documentation proactively. Most vendors who have been through procurement reviews have a security pack — a summary document covering architecture, sub-processors, certification status, and key policy commitments. Requesting this early and sharing it with the security team reduces the back-and-forth considerably.

The most common reason a martech security review takes four months instead of four weeks is not that the questions are genuinely difficult to answer. It is that the information was gathered piecemeal across multiple meetings and email threads, each with days of latency. Frontloading the documentation eliminates most of that latency.

What to Do if the Vendor Pushes Back on Detailed Questions

A vendor who declines to provide a data-flow diagram, who cannot clearly answer where hashing occurs, or who describes their sub-processors with "we use leading cloud providers" is giving you information. Not all of it is necessarily disqualifying — small vendors sometimes lack documentation maturity even when their architecture is sound — but the right response is to push for specifics, not to accept the non-answer.

The questions about data storage, hashing location, and authentication model are not exotic security requirements. They are the basic factual questions about how the product works. A vendor who has built the tool knows the answers. If they are reluctant to share them, that reluctance itself warrants explanation.

Cezium's Security Posture, Stated Directly

Cezium Ads is listed on the Salesforce AppExchange, having passed the Salesforce security review. The architecture is designed around a zero-retention principle: no customer data is stored by Cezium. When an audience is activated, Cezium generates an automation inside the customer's own Marketing Cloud instance that SHA-256 hashes identifiers before transmission — cleartext PII never leaves the customer's governed environment. Ad platform connections are OAuth 2.0, under the customer's IT team's control. Every sync produces an audit log inside the customer's own instance.

SOC 2 Type I followed by Type II is on the roadmap. For security teams that need documentation before a certification is complete, Cezium provides a data-flow diagram and a security session as part of the evaluation process. If you are working through a security review for an audience-activation tool — whether evaluating Cezium or a competitor — the framework in this post is what a thorough review looks like, and the questions to ask when replacing Advertising Studio includes additional procurement-specific guidance.

For teams currently in the Advertising Studio migration process, getting a replacement vendor through security review is often the longest part of the timeline. Starting the review process before the August 2026 renewal deadline, with documentation in hand, is the only way to avoid a gap.

Mounir Nejjai is the founder of Cezium.