Secure 360: Holistically Secure Your Salesforce Org & Data

Welcome everyone. My name is Amir Kulkarni. I'm a Salesforce architect at Slalom, founder and leader of the Salesforce Marketing Group for Fort Worth, Texas, and a 12-time certified application architect. We are joined today by Saurabh from Cloud Compliance. Before we begin, a quick disclaimer: none of this is legal advice. Everything we share today is our professional point of view based on prior experience. My name is Saurabh Gupta. I'm the co-founder of Cloud Compliance and spent about eight years at Salesforce before that. We are a native Salesforce ISV on AppExchange, focused on data privacy and security. Let's get into it. The four steps we'll walk through today: assess your org health, secure your application, secure your data, and improve security awareness. And then you repeat the cycle, because security never stops. --- Step 1: Assess your org health. Salesforce gives you three free built-in tools every org should be running regularly: Health Check, Portal Health Check, and Salesforce Optimizer. Most teams don't run them. I want to call out a specific issue for orgs using Experience Cloud or Communities: publicly shared objects. Over 70% of orgs with communities have at least one object that is publicly shared — meaning an external user, or frankly anyone with the URL, can access data without proper authorization. The Portal Health Check will surface this. Data breaches from the Verizon DBIR: 74% of breaches involve a human element — stolen credentials, privilege misuse, or social engineering. 83% are external actors, but that means 17% are insiders — your own employees with legitimate access. That access is available to them right now. The real-world examples here are Optus and Medibank. Optus had production data in lower environments — sandboxes with real customer records that were not adequately protected. Medibank had no MFA, which allowed compromised credentials to be exploited. Neither of these is exotic — they are basic controls that were missing. --- Step 2: Secure your applications. MFA is the absolute baseline. Salesforce mandates it, but some organizations have disabled it for certain users or use cases. Don't. IP restrictions: configure Salesforce to only allow logins from your corporate IP range. Users connect via VPN or certificate-based authentication. This means a stolen password is worthless unless the attacker is also on your corporate network. API access control is not enabled by default. You have to log a ticket with Salesforce support to activate it. Without it, any connected app can authenticate using a user's credentials. That means Data Loader, Workbench, or a malicious third-party tool can potentially access your entire org if credentials are compromised. Enable this. For integrations: use dedicated integration users with minimal-access profiles. Do not reuse admin credentials for integrations. The new API-only user license, at around ten to fifteen dollars per month, is purpose-built for this — it cannot log in interactively, which dramatically reduces your attack surface. Use JWT OAuth flows for service-to-service authentication. Code scanning: Salesforce Scanner is a free sfdx plugin your developers can run locally to catch SOQL injection, cross-site scripting, and with/without sharing issues before code reaches production. Checkmarx is the enterprise-grade option for organizations with large custom codebases. Salesforce also recently introduced SOQL user mode — a feature that ensures queries only return records the running user is authorized to see, even if the developer writes a broader query. Event Monitoring (Shield): this is near-real-time tracking of user activity — logins, report exports, pages visited in communities, API calls. If you are evaluating anything in the Shield portfolio and you are concerned about data exfiltration, Event Monitoring is where to start. Enhanced Transaction Security Policy extends Event Monitoring into proactive controls. You can define a policy that says: if a user attempts to export a report containing more than 100 rows of SSNs, block the action and require MFA re-verification. This is the only proactive real-time security control in Salesforce's native toolkit, and it is significantly underused. --- Step 3: Secure your data. Two considerations: production data and sandbox data. On the production side, the challenge is data volume and relevance. Gartner projected that by 2025, 80% of customer data would be governed by privacy regulations. CPRA (California), GDPR, and a growing list of US state laws all include data retention mandates — you must have a policy and you must enforce it. Keeping data you no longer need is both a regulatory liability and an unnecessary breach surface. Cloud Compliance runs 100% natively on Salesforce for data retention — no data leaves your org, no external connections. You schedule retention rules per object and per regulation, and the platform enforces them automatically. Shield Platform Encryption encrypts data at the Salesforce database layer. The customer owns the encryption key, which is the differentiator from Salesforce's classic encryption. The use case for Shield encryption is contractual or regulatory key ownership obligations. If you have a requirement to prove that you, not Salesforce, control the encryption key, this is the product. If you are buying it because you think it protects against a breach involving stolen credentials, it does not. An authorized user with valid credentials sees the data regardless of encryption. ChatGPT and generative AI: this is the new frontier. OpenAI's own terms confirm that conversations can be reviewed by OpenAI staff and used to train future models. Your employees are already using it — pasting case notes, summarizing emails, drafting responses using real customer data. For regulated industries this is a compliance problem today, not a future concern. We recently launched GPT5.ai, a native Salesforce product that anonymizes all sensitive information before it leaves the platform, sends the sanitized context to ChatGPT, and restores the original PII in the response. The user gets the full benefit of AI assistance without the data ever leaving Salesforce in an identifiable form. We are currently in pilot — reach out if you want to be included. Sandbox data: let's talk about what is actually in your sandboxes. Full and partial copy sandboxes replicate everything — accounts, contacts, PHI, financial records, product pricing, attachments, Chatter history. Your configuration settings, remote site URLs, SSO settings — all of it. Developer and Developer Pro sandboxes do not include transactional data, but they do include all user records. If you have 15,000 Salesforce users, all 15,000 email addresses, phone numbers, job titles, and SSO federation IDs are in every Developer sandbox. Those sandboxes are shared like candy — it's easy to hand access to a consultant or a new team member and assume there's no real data. There is. DataMasker replaces real data with realistic fake values entirely within your Salesforce org — nothing leaves the platform. We process about 100 million records in 24 hours. For DevOps-mature customers, we have hooks into Copado and can be triggered via REST API, so masking happens automatically on every refresh and access is gated until masking completes. The top use case we hear is preventing test emails from reaching real customers. If your sandbox deliverability is ever turned on — even briefly — every automation, trigger, and workflow can fire against real email addresses. Masking replaces those addresses before anyone gets access. --- Step 4: Security awareness. Even if your technical controls are solid, security has to be a cultural commitment. Make security training mandatory — Trailhead has excellent resources, and a quarterly 30-minute review of Health Check, Optimizer, and code scanning results keeps the baseline from drifting. The Optus and Medibank incidents were not sophisticated attacks. They were the result of missing fundamentals. The platform is secure. Your configuration and your data handling are your responsibility. --- Q&A highlights: On Shield: if you are choosing one Shield product, Event Monitoring is the most broadly useful. Enhanced Transaction Security Policy is the most powerful and the most underappreciated. On data archival: if your scenario is disaster recovery, ask yourself why that scenario is even possible — Salesforce as a multi-tenant SaaS platform has infrastructure resilience built in. The risk most organizations need to mitigate is human error: someone running a bulk delete. Address that via process controls and approval gates, not by maintaining yet another copy of sensitive data you then have to govern and secure. On data masking timing: mask immediately after every sandbox refresh, not as a manual step. For new implementations doing ETL migrations, mask before opening access to the team. For regulated-sector customers and DevOps teams, this should be fully automated. On multi-org security: if you have 20–30 Salesforce orgs, often from acquisitions, the Cloud Compliance Multi-Org Privacy Hub provides a centralized view of security policy state across all orgs without requiring full integration. Security is a cycle. The threats evolve, Salesforce adds capabilities, and new technologies create new risks. The teams that stay ahead of it are the ones that build it into the rhythm of every release, not the ones that treat it as a one-time project.