Security reviews don’t fail because you missed a checkbox. They fail because you can’t prove who can see sensitive fields, what changed, and who moved the cheese. This is a practical, engineer-friendly walkthrough of a Salesforce security review focused on field-level security (FLS) and auditing—with the exact checks, queries, and evidence packs auditors ask for.

I’ll use a “field notes” format—short sections you can run as a 90-minute review.

0) What you’re actually protecting (inventory first)

Before you touch permissions, agree on which fields matter: PII, payment details, pricing/discounts, legal flags, and anything that drives compliance. Tag them in Data Classification so you can report on them later (admins can add sensitivity and compliance tags at the field level; it pays off during audits). See Salesforce’s Data Classification overview.

Field note: If your org has no classification, start with just 10–20 risky fields across Account, Contact, Lead, Case, and Opportunity.

1) Field-Level Security that actually holds up

What to know: Field-level security (FLS) determines read/edit access to individual fields and overrides page layouts. If a layout makes a field required but FLS says read-only, read-only wins.

Modern model: Stop stuffing everything into profiles. Use Permission Sets and Permission Set Groups (muting for exceptions). That gives you least-privilege access without profile sprawl.

Quick audit (15 minutes):

• Export a list of sensitive fields (your classification list).
• Export FieldPermissions via SOQL and look for surprises (broad read on PII, edit on financials):

SELECT SObjectType, Field, ParentId, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE Field IN ('Contact.SSN__c','Account.BillingPostalCode','Opportunity.Discount__c')

• Sanity-check “super” permissions: View All Data, Modify All Data, and object-level View All/Modify All can pierce intended FLS design. Make sure only a tiny set of break-glass admins have them.

If you need a broader cleanup plan, keep this handy checklist from our team: 10 High-Impact Updates Every Salesforce Admin Should Make.

2) Prove it in the UI and the API

Auditors will ask you to demonstrate that hidden fields are really hidden.

• UI path: Log in as (or impersonate in a sandbox) a typical user and open a record with a known sensitive value. The field should be invisible or read-only.
• API path: Call the REST API as that user; absent FLS permissions, the field should not be returned or should be null. Start from Salesforce’s REST API intro if you need the endpoint basics.

Field note: Many leaks happen via reports and exports. Test a standard report and a CSV export with a non-privileged user to confirm sensitive columns aren’t available.

3) “Who changed what, when, and why?” (your audit backbone)

There are three native layers. Turn on the right ones and know the limits:

1. Field History Tracking — enable per object/field; retains up to 18 months in UI and 24 months via API. Perfect for “who changed a key field.”
2. Field Audit Trail (Shield add-on) — enterprise-grade retention (up to 10 years, and up to 60 fields/object) with policy-based archiving.
3. Setup Audit Trail — what admins changed in Setup (profiles, flows, page layouts, etc.). Download the CSV regularly.

Evidence pack to keep on hand:

• Field History report for 3–5 critical fields (before/after values, user, timestamp).
• Setup Audit Trail CSV for the last 6 months filtered to profiles/permission sets/flows.
• A one-pager that lists which fields you track and for how long (and whether Shield is in use).

4) Watch the doors and windows: Event Monitoring

Even if FLS looks clean, you still need to know who exported what and when. That’s Event Monitoring.

• Baseline: Turn on Event Log Browser or pull EventLogFile for ReportExport, BulkApi, RestApi, ListView, etc. Start with Event Monitoring.
• Near real-time: Real-Time Event Monitoring + Transaction Security lets you alert or block risky behavior (for example, exporting 50k rows from a public network).

Starter query (SOQL on EventLogFile):

SELECT EventType, LogDate, LogFileLength 
FROM EventLogFile 
WHERE EventType IN ('ReportExport','BulkApi','RestApi') 
AND LogDate = LAST_N_DAYS:7

Field note: Event Monitoring is a licensed add-on for full coverage; align the purchase with a concrete policy (e.g., “alert any ReportExport > 10k rows outside our VPN”).

5) Common “smell tests” and how to fix them

• PII visible in reports, not pages → You hid it on the layout but left Read on the field. Fix FLS, not just the layout.
• Integrations run as SysAdmin → Create an integration user with permission sets scoped to the exact objects/fields; renew tokens on a schedule.
• Profile sprawl → Consolidate into Permission Set Groups and use muting for exceptions.
• History not actually enabled → You thought it was—until you needed it. Turn on Field History Tracking for the handful of fields that really matter and test a change.
• No evidence → Schedule a monthly export of Setup Audit Trail and keep a rolling folder in your audit drive.

For a bigger operating model with AI guardrails (approvals, logging, risk tiers), grab our Agentforce governance playbook.

6) Two-week hardening sprint (copy/paste)

Week 1

• Finalize the sensitive fields list (classification).
• Lock down FLS on those fields; remove broad View All/Modify All where not needed.
• Enable Field History Tracking on 10–20 key fields and verify a test change appears in history.
• Pull Setup Audit Trail CSV and archive it.

Week 2

• Turn on baseline Event Monitoring and review 7 days of ReportExport activity.
• Create one Transaction Security policy (alert on large exports by non-admin roles).
• Script an export of FieldPermissions and stash the CSV with your audit artifacts.
• Write a 1-page evidence summary (what’s tracked, where logs live, how long you retain them).

7) Appendix: handy queries & checks

FieldPermissions (find broad read/edit on sensitive fields)

SELECT SObjectType, Field, ParentId, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE (PermissionsRead = true OR PermissionsEdit = true)
AND Field LIKE 'Contact.%'

EventLogFile (report & API exports last 30 days)

SELECT EventType, LogDate, LogFileLength
FROM EventLogFile
WHERE EventType IN ('ReportExport','BulkApi','RestApi')
AND LogDate = LAST_N_DAYS:30
ORDER BY LogDate DESC

Login history (UI path): Setup → Login History → Export → check for atypical IPs or geographies.

Bottom line

A credible Salesforce security review shows control (tight FLS) and evidence (history + logs). Classify what matters, set least-privilege at the field level, and keep receipts with history, Setup Audit Trail, and Event Monitoring. Do that, and your next audit is a demo—not a scramble. If you want help operationalizing this, our team at Revenue Ops can run a two-week hardening sprint with you.