An example security audit report and security best practices Marketing Cloud Engagement covering user roles, access controls, OWASP, data security, data hygiene, APIs, credential storage and email compliance.
Author: Crafted by Steve Weathers, Telios Guild - last updated Oct 12, 2026
B+
Good overall security. A few items to address.
The following areas demonstrate strong security practices and meet or exceed industry norms.
Each of these topics should be investigated and addressed soon to decrease risk to the business.
Review these audit findings for each of the above items
This is a sampling of security checks that can be performed in the audit. Check your current environment and recent security recommendations and make improvements on this list
Single Sign-on: Integrate Single Sign-on(SSO) with your enterprise organization to streamline password updates and access control.
Multi-Factor Authentication (MFA): For any users not using SSO and for those with Administrator roles, require MFA, and require complex passwords that expire every [90] days.
SSO Break-Glass Account: Keep one or two designated Administrator accounts exempted from Single Sign-On. This ensures emergency tenant access during identity provider (IdP) outages. See SFMC User Management Best Practices for SSO.
Revoke permissions for accounts showing zero login activity over the last 90 days.
Restrict platform UI access to corporate networks or authorized VPN blocks using the Marketing Cloud Engagement Login IP Allowlist.
Use Standard Marketing Cloud roles wherever possible.
Marketing Cloud Administrator - Each Marketing Cloud team should be supported by an Administrator to help with admin and security tasks like account enablement, password resets, IP Allowlist management, Installed Package management.
Power User - Most organizations find it helpful to create a custom Power User role for developers who need extra permissions to integrate data and create system integrations. Power Users can do many things in the system except user management, Installed package management, key management, and setup configurations.
Other Standard Roles - Content Editor / Publisher, Channel Manager, Viewer, and Security Administrator, Analyst, and Data manager will also be useful depending on how tasks are assigned in your Organization
Explicitly map users only to the specific BUs required for their daily operational scope. Make the default BU the environment where they will be working most of the time.
Establish a process and team to approve and create new users on the system.
Deactivate departing employee or contractor accounts within the platform immediately during corporate offboarding.
Enable Basic Audit Trail logging to track critical permission changes, security setting modifications, and user creation/deletion activities.
Consider paying for Advanced Audit Trail to track: edits to email content, edits to cloud pages, and data import/export activities among others.
Data Sharing Rules: Restrict cross-BU visibility by placing standard Data Extensions (DEs) inside BU-specific folders rather than the global Shared Data Extensions directory.
Shared Data Extensions: Restrict permissions on the global Shared Data Extensions folder to Read-Only for child BUs to stop accidental global record writes, except where necessary.
Sender Profiles & Delivery: Segment corporate subdomains across distinct BUs to ensure brand isolation and preserve regional deliverability.
Multi-Org Connectivity: Document the tenant architecture when mapping multiple Salesforce CRM orgs via Marketing Cloud Connect Multi-Org Configuration to prevent accidental data overwrites across BUs.
TEST or Sandbox Business Units: Ensure that any UAT or TEST BUs are on a different account or instance so that changes to Subscribers in the TEST BU do not propagate to production BUs.
Secure Headers
Consult with Developers to implement the SetResponseHeaders as recommended by Salesforce in this article: https://help.salesforce.com/s/articleView?id=002743057&type=1
Note that these options may need slight variations depending on how your pages integrate.
For sites that are not intended for public use, implement a shared secret or origin-check validation routine via Server-Side JavaScript (SSJS).
Check for PII, security or confidential data that might be exposed in the UI, DOM, or session variables.
Obfuscate necessary personal information before it is sent to be displayed so that it is recognizable to someone who already knows the data but lacks enough detail to recreate the original information. Data that is typically obfuscated: account numbers, phone numbers, email addresses, last names.
Data Input Validation: Sanitize and validate all incoming request parameters (such as SubscriberKey) on the server side before running database lookups.
Secure Form Formats: Never place cryptographic keys, cleartext passwords, or unhashed internal IDs into hidden HTML input fields.
Updating Client Data: Get IT and/or Governance approval before updating contact or customer data via a form. These forms may warrant additional security checks and monitoring.
Isolate Packages per Client Integration: Create a separate, dedicated Installed Package for each external software vendor, team or integrated system rather than pooling multiple external resources under a single credential set. If an API secret is exposed, this isolation limits the “blast radius” to the team and integrations that were entrusted with the credentials.
Naming Convention: Use clear names for Installed Packages that indicate which BU, client team and integrations are using the credentials. If Installed Packages are shared across BUs and without a consistent naming convention, it is difficult to validate which keys are still in use and almost impossible to manage required key rotations.
Key Rotation: Starting September 30, 2026 Salesforce has mandated that all OAuth 2.0 client secrets be rotated and assigned a 180 day time-to-live before the next rotation. Documenting api usage and establishing a rotation process now is highly recommended.
Avoid passing raw subscriber email addresses inside parameters or URL strings for web conversion tracking. Use the CloudPageURL() function to pass encrypted parameters safely.
Marketing Cloud email resources are intended for marketing to the public. Do not share client confidential information or PII in attachments or unauthenticated links from emails.
Audit your transactional and commercial setup regularly. Ensure transactional classifications do not contain marketing materials, allowing critical messages to bypass global commercial unsubscribes per Salesforce Send Classification Rules.
Make sure all email messages are appropriately classified as transactional or commercial.
Ensure all commercial send layouts inject dynamic unsubscribe links, physical corporate addresses, and preference center management links required under CAN-SPAM, CASL, and GDPR regulations.
Monitor deliverability, blocklists, and sender scores across all sending IPs using dedicated deliverability monitoring tools like Validity Everest. A bad sender reputation can halt email delivery to major email service providers.
Find and clean-up spam-trap and forever-bounce email addresses.
Identify email messages and email senders who are contributing to complaints, unsubscribes and reputation issues.
Unsubscribe and opt-out preferences should be honored when creating email lists for Commercial messages. Properly-categorized Transactional messages should still be sent to unsubscribed users.
Unsubscribe links should be on Commercial emails, and not on Transactional emails.
Use the AMPScript AttributeValue() function rather than raw bracket notation ([FieldName]) to safeguard against rendering breaks and page exploitation.
Always supply functional fallback default strings when calling personalization attributes to stop system script failures when resolving blank fields.
Store encryption certificates and api secrets securely within SFMC’s native Key Management system. Use DecryptSymmetric() to retrieve encrypted keys. Never store cleartext encryption keys within standard code files or content blocks.
Wrap SSJS application scripts inside structural try/catch logic blocks to trap runtime faults cleanly and log errors into a centralized debugging repository.
Enforce explicit row-level retention lifespans (30 days, 7 years) during Data Extension creation to prevent infinite cloud storage scaling as recommended in Salesforce Help: Data Retention Policy.
PII Minimization: Truncate fields during ingestion where possible (e.g., logging Email Domain instead of full addresses, or storing First Name + Last Initial instead of full names) if the data is meant purely for tracking or debugging.
Data Encryption at Rest: Implement Field-Level Encryption or tokenized authentication frameworks when storing sensitive financial, identity, or health data within Data Extensions.
Data Exports: Restrict those who can receive data exports by email by implementing the Export Email Allowlist. Limit DE export to roles who need to download that information and locations with acceptable privacy law enforcement.
Build automated SQL queries so that they execute quickly, and are resilient if they encounter up to 4 hours of server downtime. Consider the impact of daylight savings time changes on timestamps and integrated systems. Consider the impact if the prior automation is still running when the new one starts.
If SQL queries return PII or account data, suggest augmenting or anonymizing sensitive data before storing in a DE.
With JOINS, consider where rare, unexpected or “unallowed” 1:M relationships could cause unexpected SQL output (2 clicks happening at the same second, 2 primary sales reps on an account, a client buying 2 of the exact same product, same email sent to the same person 3 times in a day)
The Query Builder application is very convenient, but it may have security concerns. Check with IT before using it.
FTP has a long history of vulnerabilities. Make sure sFTP credentials are given on an as-needed basis and make sure the company policies are enforced.