The first decision is scope. A configuration review can examine profiles, permission sets, sharing rules, object permissions, field-level security, login policies, and session controls. A penetration test uses approved accounts and controlled actions to see how those settings behave together. Smaller organizations may begin with an access review, especially if they have few integrations. A global organization handling financial, health-related, or otherwise sensitive information may need testing across user roles, production-like environments, APIs, and external connections. Scope should follow risk rather than a standard package.
Salesforce access is layered, so a permission check cannot stop at the profile. Profiles establish baseline rights, permission sets can add privileges, and sharing rules affect record visibility. Field-level security may conceal a sensitive field while leaving the surrounding record available. Testers should compare those controls with actual job duties for employees, contractors, administrators, inactive users, and service accounts. A support representative may need to update a case but have no reason to export every customer. The assessment should document that mismatch and distinguish a justified exception from an unnecessary privilege.
Connected applications deserve the same scrutiny as human users. Review OAuth scopes, connected app settings, API credentials, token lifetime, secret storage, IP restrictions, and revocation procedures. An integration account that can read every contact may only need campaign members, yet its broad access could expose much more if the vendor account is compromised. Testers should confirm what happens after an employee changes roles or a supplier leaves. A useful practical step is to compare the access listed in the integration inventory with the permissions actually observed during an approved test, rather than relying on an old spreadsheet.
The rules of engagement should be agreed to before testing begins. Confirm whether work will occur in a sandbox, a cloned environment, or production with tightly limited actions. Record the approved accounts, test windows, emergency contacts, blackout periods, data-handling rules, and prohibited activity. A careful provider should avoid mass emails, destructive updates, unnecessary customer-data collection, and automation that could create real business effects. Ask how evidence will be redacted and stored. A permission comparison, sanitized record path, or screenshot with sensitive fields removed can help administrators reproduce a finding without circulating customer information.
A strong report connects each weakness to an operational decision. Rather than labeling a sharing rule broadly permissive, identify the affected object, roles, record types, exposure path, and data sensitivity. Severity should reflect what access was gained, how feasible the path is, and which safeguards remain. Recommendations might include narrowing a permission set, revising sharing logic, rotating credentials, restricting a connected app, or improving audit visibility. The report should also state testing limits and validation steps. Compliance mapping can support an organization’s obligations, but a compliance reference by itself does not establish secure configuration.
Provider selection should cover assessor experience, Salesforce architecture, integration testing, production safety, report quality, and retesting practice. Ask to see how a corrected finding will be checked, since a setting change can solve one path while leaving a related permission intact. A recurring salesforce security assessment can help detect configuration drift, while periodic manual testing can examine attack paths that automated checks may miss. Reassess after major deployments, new integrations, permission changes, acquisitions, or staffing changes. Keeping the current access inventory beside the latest test report prevents teams from rebuilding the same scope from memory.
