Org Security Settings in Salesforce

Org Security Settings in Salesforce

Welcome to Post 29 of our Salesforce series! In the previous post, we covered User Authentication and SSO — how users prove their identity when logging in. But authentication is just the front door. Once users are inside your org, there’s a whole layer of security settings that govern how sessions behave, what password strength is required, how file access works, what data is encrypted, and how you monitor everything happening in the org.

This post covers the settings that protect your Salesforce org at the platform level. Think of these as the walls, cameras, locks, and alarm systems of your Salesforce house. Authentication is the key that gets you in the door — org security settings are everything else.

Session Settings

Session settings control how Salesforce manages user sessions after login. A “session” is the period between when a user logs in and when they log out (or are automatically logged out). Getting session settings right is a balance between security and user convenience.

Where to Find Session Settings

Go to Setup → Session Settings.

You’ll see a dense page with many options. Let’s break down the important ones.

Session Timeout

This controls how long a session stays active when the user is idle.

How to configure:

1. Go to Setup → Session Settings.
2. Under Session Timeout, set the Timeout Value dropdown to your desired duration.
3. Options range from 15 minutes to 24 hours.
4. Click Save.

Best practices:

• For most orgs, 2 hours is a reasonable default.
• For orgs handling sensitive data (healthcare, finance), consider 30 minutes to 1 hour.
• Keep the timeout warning popup enabled so users can save their work before being logged out.
• Remember that a shorter timeout means more frequent re-authentication, which can frustrate users working on long tasks.

Session Security Levels

Salesforce assigns a security level to each session based on how the user authenticated:

You can require high assurance sessions for specific actions:

1. Go to Setup → Session Settings.
2. Under Session Security Levels, you can configure which login methods qualify as High Assurance.
3. Certain features (like Reports, Connected Apps, or API access) can be configured to require a High Assurance session.

This is how you enforce MFA for specific sensitive operations without requiring it for every login.

Lock Sessions to the IP Address

Enabling IP-based session locking adds protection against session hijacking. If someone steals a session token and tries to use it from a different network, it won’t work.

Caution: If your users are on mobile networks where IP addresses change frequently (like cellular data), IP-based session locking can cause unexpected logouts.

Other Important Session Settings

Step-by-step for a secure baseline:

1. Go to Setup → Session Settings.
2. Under Session Timeout, set to your org’s required idle timeout.
3. Under Session Settings, enable:
   • Lock sessions to the IP address from which they originated (if your users have stable IPs)
   • Require HttpOnly attribute
   • Enable clickjack protection for Setup pages
   • Enable clickjack protection for non-Setup Salesforce pages
   • Enable clickjack protection for Visualforce pages with headers enabled
   • Enable CSRF protection on GET requests
   • Enable CSRF protection on POST requests
   • Enable Content Sniffing protection
4. Click Save.

Note: Some of these settings can break integrations or custom Visualforce pages that rely on embedding Salesforce in iframes. Test in a sandbox before enabling in production.

Session Management

While Session Settings are the org-wide policies, Session Management gives you real-time visibility into active sessions and the ability to terminate them.

Where to Find Session Management

Go to Setup → Session Management.

What You Can See

The Session Management page shows all active sessions in your org:

Terminating Sessions

You can forcibly end any active session:

1. Go to Setup → Session Management.
2. Find the session you want to terminate.
3. Click Remove next to the session.

The user is immediately logged out and must re-authenticate.

When to terminate sessions:

• An employee has been terminated and you need immediate access revocation (don’t just deactivate their user — kill their active sessions too).
• You suspect a compromised account and need to force a re-authentication.
• A user reports suspicious activity on their account.
• During a security incident response.

Session Management Best Practices

• Check session management after deactivating a user. Deactivating a user prevents future logins but does NOT terminate existing sessions. Always revoke active sessions when deactivating a user.
• Monitor for unusual session patterns. Multiple concurrent sessions from different geographic locations could indicate credential compromise.
• Use session management during security audits. It gives you a real-time snapshot of who is logged in and how.

Password Policies

Password policies control the rules around user passwords — complexity requirements, expiration, lockout, and more. Even if you’re using SSO for most users, you still need password policies for admin accounts and as a fallback.

Where to Find Password Policies

Go to Setup → Password Policies.

Password Policy Settings

Here’s a breakdown of every setting on the Password Policies page:

How to Configure Password Policies

1. Go to Setup → Password Policies.
2. Set each value according to your org’s security requirements.
3. Click Save.

Password Policy Configuration Example

Here’s a solid baseline for a mid-size org:

Profile-Level Password Policies

You can override the org-wide password policy for specific profiles. This is useful when different user groups have different security requirements.

1. Go to Setup → Profiles.
2. Open the profile.
3. Scroll to (or search for) Password Policies.
4. Override any of the org-wide settings for this profile.

Example use case: Your standard users follow the org-wide 90-day expiration, but your admin profile requires password changes every 30 days.

Password Policy Best Practices

• Move toward passwordless where possible. MFA and SSO reduce the importance of password complexity policies. The strongest password policy is not needing a password at all.
• Don’t set expiration too aggressively. Research shows that forcing frequent password changes leads to weaker passwords (users pick predictable patterns like “Summer2026!” → “Fall2026!”). If you have MFA enabled, consider longer expiration periods or no expiration.
• Always enforce lockout. Five failed attempts with a 30-minute lockout is a solid default. This protects against brute-force attacks.
• Monitor login failures. Use login history reports to identify accounts experiencing repeated failed login attempts — this could indicate an attack.

What Is Event Monitoring

Event monitoring is Salesforce’s auditing and analytics framework that tracks user activity across your org. It captures detailed logs of who did what, when, and from where. If session management is your real-time camera feed, event monitoring is the recorded footage you can review later.

Event Monitoring Overview

Event monitoring is part of the Salesforce Shield add-on (or available as a standalone purchase). It provides two main capabilities:

1. Event Log Files — Detailed CSV logs of user activity, downloadable via API.
2. Real-Time Event Monitoring — Streaming events that can trigger automated actions.

What Events Are Tracked

Event monitoring captures a wide range of activities:

How to Access Event Log Files

Event log files are accessed through the Salesforce API (they are not visible in the standard Setup UI):

Using the API (Workbench or similar tool):

1. Open Workbench or your preferred API tool.
2. Run a SOQL query: SELECT Id, EventType, LogDate, LogFileLength FROM EventLogFile WHERE LogDate = TODAY
3. Download the log file using the returned ID.
4. Open the CSV file to analyze the data.

Using the Event Monitoring Analytics App:

Salesforce provides a pre-built analytics app for event monitoring data:

1. Go to Setup → Event Monitoring Settings.
2. Enable Event Monitoring Analytics.
3. Navigate to the Event Monitoring app in the App Launcher.
4. Browse pre-built dashboards for login activity, API usage, report exports, and more.

Event Log File Retention

If you need longer retention, export the log files to an external system (Splunk, Datadog, a data lake, etc.) before they expire.

Common Event Monitoring Use Cases

• Security auditing — Track who exported sensitive report data, who logged in from unusual locations, who accessed restricted records.
• Compliance — Demonstrate to auditors that you’re monitoring user activity and can produce audit trails.
• Performance troubleshooting — Identify slow pages, expensive SOQL queries, and API bottlenecks using Apex execution and API event logs.
• Adoption tracking — Monitor which features users are actually using (Lightning page views, reports run, dashboards viewed).
• Data loss prevention — Track bulk data exports and content downloads to ensure sensitive data isn’t being exfiltrated.

How to Set Up Transaction Security Policies

Transaction Security is the enforcement arm of event monitoring. While event monitoring logs activity for later review, transaction security policies evaluate events in real time and take automated action.

What Is Transaction Security?

Transaction security policies let you define conditions on events and specify actions to take when those conditions are met. For example:

• If a user logs in from an unrecognized IP address, then require MFA step-up authentication.
• If a user exports a report containing more than 1,000 rows, then block the export and notify the admin.
• If an API session is created from outside the US, then end the session immediately.

Transaction Security Components

How to Set Up a Transaction Security Policy

Prerequisites:

• You need the Salesforce Shield or Event Monitoring license.
• Enable Transaction Security in Setup.

Step 1: Enable Transaction Security

1. Go to Setup → Transaction Security Policies.
2. If this is your first time, you’ll see a prompt to enable the feature.
3. Click Enable.

Step 2: Create a Policy Using Condition Builder

The Condition Builder is the declarative (no-code) way to create policies:

1. Go to Setup → Transaction Security Policies.
2. Click New (or Create a Policy).
3. Select the Event Type (e.g., “Login Event,” “Report Event,” “API Event”).
4. Choose Condition Builder as the evaluation method.
5. Define your conditions:

Example — Block Logins from Outside Business Hours:

6. Select the Action:

   • Block — Prevents the event from completing.
   • Multi-Factor Authentication — Requires MFA step-up before proceeding.
   • Notification Only — Logs the event and sends a notification without blocking.

7. Configure Notifications:

   • Select who should be notified (specific users or groups).
   • Notifications are sent via email and/or in-app.

8. Click Save and Enable the policy.

Step 3: Create a Policy Using Apex (Advanced)

For complex conditions that the Condition Builder can’t handle, you can write an Apex class:

global class BlockLargeReportExport implements TxnSecurity.PolicyCondition {
    public boolean evaluate(TxnSecurity.Event e) {
        // Get the number of rows in the report export
        Integer rowCount = Integer.valueOf(e.getAttribute('NumberOfRows'));
        // Block if more than 2000 rows
        return rowCount > 2000;
    }
}

Then create the policy in Setup and select this Apex class as the condition.

Transaction Security Policy Examples

Here are some common policies that organizations implement:

Policy 1: Require MFA for Report Exports

Policy 2: Block Bulk Data Exports Outside Business Hours

Policy 3: Alert on Login from New Device

Transaction Security Best Practices

• Start with Notification Only. Before blocking anything, run policies in notification-only mode to understand the impact. You don’t want to accidentally block legitimate users.
• Test in sandbox first. Transaction security policies can disrupt workflows if misconfigured. Always validate in a sandbox.
• Don’t create too many policies. Each policy adds evaluation overhead to the event. Keep the number reasonable and focused on high-risk events.
• Review policy triggers regularly. Check which policies are firing and whether they’re catching real issues or generating false positives.

How to Set Up Event Monitor Reports

While the Event Monitoring Analytics App provides pre-built dashboards, you can also build custom reports on event data for ongoing monitoring. This gives you the flexibility to track exactly what matters to your org.

Using Event Monitoring Analytics App

If you have the Event Monitoring license, the analytics app is the easiest starting point:

1. Go to Setup → Event Monitoring Settings.
2. Ensure Event Monitoring Analytics is enabled.
3. Open the App Launcher and search for Event Monitoring.
4. The app includes pre-built dashboards:

Building Custom Reports on Login History

Even without the Event Monitoring add-on, every Salesforce org has access to Login History, which you can report on:

1. Go to Setup → Login History (for a quick view).

2. To build a report:

   • Go to the Reports tab.
   • Click New Report.
   • Search for the Login History report type (under Administrative Reports).
   • Add columns: Username, Login Time, Source IP, Login Type, Status, Browser, Platform.
   • Add filters as needed (e.g., Status = “Failed” to see failed login attempts).
   • Group by Username to see login patterns per user.
   • Save the report.

3. Schedule the report to run daily or weekly and email results to the security team.

Building Custom Reports on Setup Audit Trail

The Setup Audit Trail tracks changes to your org’s configuration (not user data, but admin changes):

1. Go to Setup → View Setup Audit Trail (for recent changes).

2. To build a report or download the full history:

   • On the Setup Audit Trail page, click Download to get the last 180 days of setup changes as a CSV.
   • The CSV includes: Date, User, Action, Section, Delegate User.

3. For an ongoing report, use the SetupAuditTrail object in a custom report type or query it via API:

SELECT CreatedDate, CreatedBy.Name, Action, Section, Display
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:30
ORDER BY CreatedDate DESC

Building Dashboards for Security Monitoring

Create a security monitoring dashboard with these components:

Step-by-step to build the dashboard:

1. Create each of the reports listed above.
2. Go to the Dashboards tab.
3. Click New Dashboard.
4. Name it “Org Security Monitoring.”
5. Drag components onto the dashboard canvas.
6. For each component, select the source report and choose the chart type.
7. Set the Running User to an admin who has access to all the data.
8. Save the dashboard.
9. Schedule the dashboard to refresh daily.

Note: Event Log File reports require the Event Monitoring license. Login History and Setup Audit Trail reports are available in all editions.

Files Security

Salesforce stores files (attachments, Salesforce Files, documents) in its cloud infrastructure. File security settings control how files are scanned, shared, and accessed.

Where to Find File Security Settings

Go to Setup → Files → Content Deliveries and Public Links and Setup → Files → General Settings.

Key File Security Settings

File Upload and Download Security

This is a critical setting that controls how different file types are handled when users try to download or preview them:

1. Go to Setup → File Upload and Download Security.
2. You’ll see a list of file types (HTML, SVG, XML, etc.).
3. For each type, set the behavior:

Best practice: Set HTML, SVG, and other executable file types to Download mode. This prevents stored cross-site scripting (XSS) attacks where a malicious user uploads an HTML file containing JavaScript, and another user opens it in their browser.

Content Deliveries and Public Links

Content deliveries let users create shareable links to files — even for recipients who don’t have a Salesforce login:

How to enable/disable:

1. Go to Setup → Content Deliveries and Public Links.
2. Enable or disable:
   • Content Deliveries feature — Master toggle for the feature.
   • Allow Content Deliveries to be created — Per-user control via profiles/permission sets.

Security considerations:

• Public links bypass all Salesforce authentication. Anyone with the link can access the file.
• Consider disabling public links for orgs handling sensitive data.
• If you allow public links, use the password protection option on deliveries.
• Set expiration dates on content deliveries so links don’t remain active indefinitely.
• Disable the option to allow recipients to download if you only want them to preview files.

File Scanning and Malware Protection

Salesforce provides basic file scanning capabilities:

• Files uploaded through Salesforce are scanned for known malware signatures.
• Infected files are quarantined and cannot be downloaded.
• File scanning works automatically — no configuration needed.

For enhanced file security, consider integrating with a third-party file scanning solution via the ContentVersion trigger or an AppExchange package.

Platform Encryption (Shield)

Platform Encryption is part of Salesforce Shield and provides encryption at rest for sensitive data stored in Salesforce. It goes beyond the standard encryption that Salesforce applies to all data, giving you control over which specific fields and files are encrypted with keys that you manage.

Standard Encryption vs. Shield Platform Encryption

What Can Be Encrypted

Platform Encryption can encrypt:

Standard Fields:

• Account: Name, Phone, Fax, Description
• Contact: Name, Email, Phone, Mailing Address
• Case: Subject, Description
• And many more across standard objects

Custom Fields:

• Text, Text Area, Long Text Area, Email, Phone, URL, Date, DateTime fields on custom objects

Files and Attachments:

• Salesforce Files (ContentVersion)
• Attachments
• File previews and thumbnails

Other Data:

• Chatter posts and comments
• Search index
• Custom metadata (with certain limitations)

How to Set Up Platform Encryption

Step 1: Enable Shield Platform Encryption

1. Go to Setup → Platform Encryption → Encryption Policy.
2. If prompted, accept the terms and enable the feature.

Step 2: Generate or Upload an Encryption Key

1. Go to Setup → Platform Encryption → Key Management.
2. Click Generate Tenant Secret (for Salesforce-managed keys).
3. Select the secret type:

4. Click Generate.

Alternatively, upload your own key material using Bring Your Own Key (BYOK) for maximum control:

1. Go to Key Management → Bring Your Own Key.
2. Upload a 256-bit AES key wrapped with a Salesforce-provided certificate.
3. Salesforce uses your key to encrypt the data.

Step 3: Select Fields to Encrypt

1. Go to Setup → Object Manager → [Object] → Fields.
2. Open the field you want to encrypt.
3. If the field type supports encryption, you’ll see an Encrypted checkbox or option.
4. Check the box and save.

Or use the Encryption Policy page:

1. Go to Setup → Platform Encryption → Encryption Policy.
2. Click Encrypt Fields.
3. Select the object and fields to encrypt.
4. Choose the encryption scheme:
   • Probabilistic — Stronger encryption but no search/filter support on the field.
   • Deterministic — Slightly less entropy but supports exact-match search, filtering, and SOQL WHERE clauses.
5. Save.

Step 4: Encrypt Files (Optional)

1. Go to Setup → Platform Encryption → Encryption Policy.
2. Under Encrypt Files, toggle the setting to On.
3. All new files will be encrypted. Existing files can be encrypted using the background encryption service.

Key Rotation

Encryption best practices require periodic key rotation:

1. Go to Setup → Platform Encryption → Key Management.
2. Click Generate Tenant Secret to create a new key.
3. The new key is used for all new data encryption.
4. Existing data remains encrypted with the old key until you run Background Encryption.
5. Go to Setup → Platform Encryption → Encryption Statistics.
6. Click Encrypt to re-encrypt existing data with the new key.
7. Archive the old key (don’t destroy it until re-encryption completes).

Platform Encryption Considerations

• Encrypted fields have limitations. Some features don’t work with encrypted fields: formula references, workflow field updates to encrypted fields, SOQL LIKE queries on probabilistically encrypted fields, and some validation rule functions.
• Performance impact is minimal. Salesforce designed Shield encryption to have negligible performance impact for most operations.
• Plan your encryption strategy before enabling. Changing a field from encrypted to unencrypted (or vice versa) requires careful planning and testing.
• Deterministic vs. probabilistic is a key decision. Use deterministic encryption for fields you need to search/filter on. Use probabilistic for maximum security on fields that don’t need search.
• Test in sandbox first. Enable encryption in a full-copy sandbox and test all your reports, searches, workflows, and integrations before rolling out to production.

Field PII Settings

PII (Personally Identifiable Information) classification in Salesforce helps you identify and manage fields that contain sensitive personal data. This is critical for compliance with privacy regulations like GDPR, CCPA, and HIPAA.

What Are Field PII Settings?

Salesforce lets you classify fields based on the type of data they contain. This classification doesn’t enforce any security on its own — it’s a labeling system that helps you:

1. Identify which fields contain PII.
2. Report on PII field usage across your org.
3. Apply appropriate security controls (encryption, FLS, masking) to those fields.
4. Respond to data subject access requests (DSARs) by knowing exactly where personal data lives.

Data Classification Fields

Each field in Salesforce has optional classification metadata:

How to Set PII Classifications

For individual fields:

1. Go to Setup → Object Manager → [Object] → Fields & Relationships.
2. Click on the field name.
3. Scroll down to the Data Classification section (or Data Sensitivity section).
4. Set the classification values:
   • Compliance Categorization
   • Data Sensitivity Level
   • Data Owner
   • Field Usage Description
5. Click Save.

For bulk classification:

1. Go to Setup → Data Classification (or search “Data Classification” in Quick Find).
2. Use the Data Classification tab to view all fields and their current classifications.
3. Edit classifications in bulk using the inline editing interface.
4. Click Save.

Building a PII Inventory

A PII inventory is a complete map of where personal data lives in your org. Here’s how to build one:

Step 1: Export all field metadata using the Metadata API or a tool like Salesforce Inspector.

Step 2: For each field, determine:

• Does it contain PII? (Name, email, phone, address, SSN, date of birth, etc.)
• What category of PII? (Direct identifier, quasi-identifier, sensitive data)
• What regulations apply? (GDPR for EU residents, CCPA for California residents, etc.)

Step 3: Set the Data Classification metadata on each field in Salesforce.

Step 4: Create a report or dashboard that shows:

• All fields classified as “Confidential” or “Restricted”
• All fields with a compliance categorization of “GDPR” or “CCPA”
• All fields without a classification (these need review)

PII Best Practices

• Classify ALL fields, not just the obvious ones. Custom text fields, formula fields, and even lookup fields can contain PII. A lookup to Contact contains the contact’s name.
• Review new fields regularly. Add data classification to your field creation process — every new field should be classified before deployment.
• Use encryption for high-sensitivity PII. Fields classified as “Restricted” or “MissionCritical” should be encrypted with Shield Platform Encryption.
• Restrict FLS for PII fields. Users who don’t need to see PII fields should have those fields hidden via field-level security.
• Document your PII inventory. Regulators and auditors will ask for it. Having it in Salesforce’s native data classification makes it easy to produce.

Field Audit Trail

Field Audit Trail is a Salesforce Shield feature that extends the standard field history tracking from a 18-to-24-month retention to up to 10 years. It stores historical field values in a big object called FieldHistoryArchive, giving you a long-term audit trail of changes to sensitive data.

Standard Field History Tracking vs. Field Audit Trail

How Field Audit Trail Works

1. You define a Field History Retention Policy that specifies which objects and fields to track.
2. When a tracked field is changed, Salesforce captures the old value, new value, who made the change, and when.
3. Data within the standard retention window (18–24 months) is stored in the regular [Object]History objects (e.g., AccountHistory, OpportunityHistory).
4. When data ages past the retention window, it’s archived to the FieldHistoryArchive big object instead of being deleted.
5. The FieldHistoryArchive retains the data for up to 10 years (configurable).

How to Set Up Field Audit Trail

Step 1: Define a Field History Retention Policy

You define the policy using a metadata file. This is done through the Metadata API or a deployment tool (Salesforce CLI, VS Code, change sets with metadata).

The policy is defined in an XML file called HistoryRetentionPolicy:

<?xml version="1.0" encoding="UTF-8"?>
<HistoryRetentionPolicy xmlns="http://soap.sforce.com/2006/04/metadata">
    <archiveAfterMonths>18</archiveAfterMonths>
    <archiveRetentionYears>10</archiveRetentionYears>
    <description>Field Audit Trail policy for Account and Contact</description>
    <gracePeriodDays>1</gracePeriodDays>
    <historyRetentionPolicyDetails>
        <fieldHistory>
            <field>Account.AnnualRevenue</field>
        </fieldHistory>
        <fieldHistory>
            <field>Account.OwnerId</field>
        </fieldHistory>
        <fieldHistory>
            <field>Account.Rating</field>
        </fieldHistory>
        <fieldHistory>
            <field>Contact.Email</field>
        </fieldHistory>
        <fieldHistory>
            <field>Contact.Phone</field>
        </fieldHistory>
    </historyRetentionPolicyDetails>
</HistoryRetentionPolicy>

Step 2: Deploy the Policy

Deploy the metadata file to your org using Salesforce CLI:

sf project deploy start --metadata HistoryRetentionPolicy

Or include it in a change set or metadata package.

Step 3: Enable Field History Tracking on the Target Fields

For the audit trail to capture changes, the underlying field history tracking must be enabled:

1. Go to Setup → Object Manager → [Object] → Fields & Relationships.
2. Click Set History Tracking.
3. Check the fields you want to track.
4. Click Save.

The fields listed in your retention policy should also be enabled in field history tracking.

Step 4: Query Archived Data

To query the archived data, use SOQL on the FieldHistoryArchive object:

SELECT ParentId, FieldHistoryType, Field, OldValue, NewValue,
       CreatedDate, CreatedById
FROM FieldHistoryArchive
WHERE ParentId = '001XXXXXXXXXXXX'
AND FieldHistoryType = 'Account'
ORDER BY CreatedDate DESC

Note: Queries on FieldHistoryArchive are asynchronous for large datasets. Use the queryMore pattern for pagination.

Field Audit Trail Configuration

What to Track with Field Audit Trail

Focus on fields where you need a long-term record of changes for compliance or legal reasons:

Field Audit Trail Best Practices

• Be selective about which fields to track. You have a limit of 60 fields per object. Prioritize fields where historical changes have compliance, legal, or business significance.
• Don’t track fields that change constantly. Fields like “Last Modified Date” or formula fields that recalculate frequently will generate enormous volumes of history data.
• Plan for querying. The FieldHistoryArchive big object is designed for write-heavy, read-moderate workloads. Complex ad-hoc queries may be slow. Build scheduled reports or extract data to an analytics platform for regular analysis.
• Combine with Platform Encryption. For the most sensitive fields, use both Field Audit Trail (to track who changed the data) and Platform Encryption (to protect the data at rest).
• Test the retention policy in sandbox. Deploy and validate in a full-copy sandbox before production. Verify that archived data is accessible and that your queries return expected results.

Putting It All Together: An Org Security Checklist

Here’s a practical checklist for configuring org security in a Salesforce org. Use this as a starting point and adjust based on your organization’s specific compliance and security requirements.

Session and Authentication Security

Password Security

Monitoring and Auditing

Data Protection

Section Notes

Here are the key takeaways from this post:

• Session settings are your first line of defense after authentication. Configuring timeouts, clickjack protection, CSRF protection, and secure connections protects against a wide range of attacks. Don’t leave these at defaults — review and harden them for your org.

• Password policies should balance security with usability. Long, complex passwords with MFA are better than short passwords that change every 30 days. If you’ve adopted SSO and MFA, consider relaxing password expiration requirements.

• Event monitoring turns your org into a glass box. With event log files, you can see exactly what every user is doing — from API calls to report exports to page views. This data is essential for security investigations and compliance audits.

• Transaction security policies give you real-time enforcement. Instead of reviewing logs after the fact, transaction security policies block or challenge suspicious activity as it happens. Start with notification-only policies and graduate to blocking after you understand your org’s patterns.

• Platform Encryption meets compliance requirements that standard Salesforce encryption doesn’t cover. If you’re in a regulated industry (healthcare, finance, government), Shield Platform Encryption is likely a requirement, not an option.

• Field PII classification is a labeling system, not an enforcement mechanism. It doesn’t secure data on its own, but it makes it dramatically easier to identify where sensitive data lives so you can apply the right security controls.

• Field Audit Trail extends your audit history from months to years. For fields where you need to prove who changed what and when — for legal, regulatory, or contractual reasons — Field Audit Trail is the tool. Combine it with encryption for defense in depth.

• Security is layered. No single feature makes your org secure. The combination of session settings + password policies + event monitoring + encryption + audit trails creates a robust security posture. Think of it as defense in depth.

This is Part 29 of the Salesforce series. Next up: Creating Translations in Salesforce — how to make your Salesforce org multilingual with the Translation Workbench, translated labels, and language-specific customizations.