Begin with the permission model and document the intended access for each job function. Profiles provide baseline capabilities, while permission sets can add rights without changing the profile. Object permissions determine whether someone can read, create, edit, or delete records. Field-level security can restrict individual fields, such as a personal phone number, even when the user can open the surrounding record. Review permission set groups, delegated administration, and inherited assignments as well. A useful habit is to compare the access matrix with a real user list before testing, since an accurate design document does not help if old assignments remain active.
Record visibility needs its own review. Organization-wide defaults establish the starting level of sharing, but role hierarchies, sharing rules, account teams, territories, groups, and manual shares may expand access. A representative from sales might see an account through the role hierarchy, while a service user reaches it through a group-based rule. Test accounts from different departments and inspect what those users can actually open, edit, export, or search. The Salesforce Security Testing process should identify combinations that create excessive access, even when each individual setting appears reasonable.
Connected applications add a separate route into the organization. An integration uses an API to exchange information with Salesforce, and its OAuth token functions as a delegated credential. Scope, user context, storage, and expiration therefore deserve review. A marketing connector that reads every contact exposes more data than one restricted to approved objects and fields. Inventory connected apps, integration users, scopes, client secrets, and authentication failures. Revoke a test user or token and verify that access actually stops. Also trace exports into reporting stores, spreadsheets, or other systems where Salesforce controls may no longer apply.
Effective testing combines configuration analysis with behavior checks. A scanner can review metadata, permissions, sharing settings, and known configuration weaknesses quickly, but it cannot decide whether every business exception is justified. Manual tests using approved test accounts should attempt realistic actions: opening another region’s account, downloading a report, changing ownership, or viewing a restricted field through search. Keep screenshots, request details, and timestamps with each finding. Logs show what occurred, while alerts may reveal unusual downloads or repeated failed sign-ins. Rank issues by exposure and likely effect rather than treating every inconsistency as urgent.
Consider a support team that needs case details but not full payment information. A field permission review may look correct while a report folder, dashboard, mobile view, or integration still exposes the field. Test the complete path a worker follows, including search results, list views, exports, and downstream applications. If a report is involved, open the report as the test user rather than checking only its folder assignment. Fix the narrowest control that resolves the exposure: remove an unnecessary permission, tighten a sharing rule, reduce an OAuth scope, or separate an integration user. Retest related roles after each change because access can shift elsewhere.
Security testing should follow changes to the environment instead of ending after an initial cleanup. New objects, packages, flows, users, and connected applications can alter effective access. Schedule reviews around major releases and high-risk changes, and assign every finding an owner, evidence record, due date, and status. Approved exceptions should include a reason and expiration date so temporary access does not become permanent. Teams can use salesforce security insights to support recurring reviews, but their own configuration, test results, and logs should determine decisions. Keep a short retest checklist with the change ticket to prevent the same verification work from being repeated.
