Salesforce permits customer security assessments without prior approval or pretest notification, subject to its Security Assessment Agreement. That policy sentence is a starting point, not a complete authorization for a third-party penetration test. The agreement ties testing to an applicable service directly connected to the customer's account and places a separate prior-written-approval condition on subcontracting or transferring assessment rights (Salesforce, Security Assessment Agreement).
Quick answer. A Salesforce customer-org penetration test should measure whether the customer's configuration and custom application expose records or actions to the wrong user, guest, partner or integration identity. Scope object, field and record authorization, custom Apex and Experience Cloud, then test each path with controlled accounts and synthetic data. Before a third-party engagement, the customer should resolve Salesforce's written-approval condition and the agreement's method, timing, reporting and stop requirements (Salesforce, Security Assessment Agreement).
This is a procurement and test-design guide for a US or Canadian enterprise that owns a customized Salesforce org. It is meant to make a statement of work reviewable by its CRM owner, security team and procurement counsel. It addresses what to test in the customer's account and how to recognize an adequate report. It does not turn permission to assess a purchased service into permission to probe other customers, Salesforce infrastructure or a linked vendor's environment.
The purchase decision: customer configuration or provider assurance?
A Salesforce deployment is rarely one uniform application. It may include internal CRM objects, custom objects, Apex, Lightning components, Experience Cloud sites, connected apps, data feeds and partner workflows. The buyer has to identify which of these are customer-controlled and which assessment evidence would change a decision. A request to “pentest Salesforce” leaves that work to the tester and invites a generic scan.
The first distinction is between Salesforce's platform security and the customer's implementation. A provider report can describe testing of a service. A customer-org assessment can examine the access model, code, guest pages and integrations the customer configured. If the procurement concern is whether a partner can read another partner's case, a platform-level assurance package will not answer it. If the concern is Salesforce's shared infrastructure, a customer-org test is not the authorized vehicle. The agreement limits traffic to the customer's accounts and excludes Salesforce IP-address testing (Salesforce, Security Assessment Agreement, section 2).
A second distinction is between ordinary connected-app governance and this org-specific test. Our SaaS OAuth and connected-app scope follows delegated tokens across a SaaS estate. Here, a token is one of several identities used to validate Salesforce object, field and record boundaries inside a named customer org. The test can include an integration account's effective rights, but a full survey of every connected app is a separate piece of work.
A third distinction is environment. The agreement describes assessments of applicable purchased services and customer accounts, while the SOW should name the exact production or sandbox orgs, their instance details, and whether test data can be created there. A sandbox can make business-flow testing safer, but a sandbox result only proves the configuration and code actually deployed in that sandbox. Compare its permission sets, sharing rules and Apex version with production before treating the result as production assurance. That comparison is an acceptance item, not an implied property of Salesforce sandboxes.
Read Salesforce's rules before writing the SOW
The June 2026 Security Assessments help article says prior approval and pretest notification are no longer required for customer assessments. It also says every assessment must follow the Security Assessment Agreement. The agreement allows a web application assessment or nonintrusive domain-URL network testing directly connected to the customer account, subject to its terms. It is not an open invitation to run any technique against any Salesforce property.
The contract review has a separate third-party issue. Section 2(c) says the customer may not subcontract, assign or transfer the granted rights or obligations without Salesforce's prior written approval. It also requires a third party to meet equivalent confidentiality and security duties, and leaves the customer responsible for that party's acts. A buyer using an outside pentest firm should have the approval and contract position settled by the parties before scheduling active testing. The June help article's removal of general prior assessment approval does not silently erase this agreement clause.
The same agreement restricts testing to the customer's accounts. It bars denial of service, reboot attempts, malware and EICAR upload, test sales leads, Salesforce IP-address testing and listed Salesforce public forms. If remote code execution is reached, the agreement requires immediate Salesforce notification and forbids further privilege escalation or lateral movement. It restricts all automated testing to Friday 21:00 PST through Sunday 23:59 PST, and bars testing during a major upgrade or maintenance window. These are contract terms to validate against the current agreement, not assumptions a vendor should bury in generic rules of engagement (Salesforce, Security Assessment Agreement, section 2).
Reporting needs particular care. The agreement calls for a written report, immediate reporting of High findings and restricted disclosure. Its Exhibit A asks for a severity summary, technical detail, reproducibility, applicable HTTP requests and responses, and explanation of why the behavior is a finding. It says raw scanner data alone is insufficient. Salesforce's newer help article gives different contact direction from the older agreement's report-submission language. The customer should resolve the current reporting route and any incident escalation channel directly with Salesforce before scope signoff; the SOW should record the resolution, rather than guess a channel from either page (Salesforce agreement; Salesforce Security Assessments).
The agreement also points to a linked list of excluded services and gives special restrictions for MuleSoft workers. If the program includes Salesforce-branded products beyond the named CRM org, list each service separately and verify its current eligibility. The buyer should never let a broad master-services phrase stand in for an account and service inventory.
Figure 1: A Salesforce customer-org SOW names the purchased service and customer account while excluding other accounts and provider infrastructure. Source: Salesforce, Security Assessment Agreement.
Build an access matrix before selecting test cases
The core deliverable is a permission matrix that states what each identity should and should not do. Salesforce's own secure-coding material separates object-level, field-level and record-level authorization, and explains that Apex data-operation mode and sharing declarations change how those boundaries are enforced (Salesforce Developers, CRUD and FLS; sharing rules). A test of a single admin account cannot establish whether a restricted user is correctly restricted.
Use business identities, not only technical profiles. A sales representative, regional manager, service agent, partner user, guest visitor and integration identity may all touch the same object by different routes. The matrix should capture expected read, create, change, delete and export behavior for sensitive object and field combinations. It should identify the data owner who approves each expected result. Permission names alone are weak acceptance criteria because custom Apex, flows or integrations can change what an identity can do.
Boundary | Buyer supplies | Tester proves with authorized identities | Evidence to retain |
|---|---|---|---|
Object | Sensitive standard and custom objects, CRUD expectations by role | A restricted identity cannot perform an object action through UI or exposed API merely because another path exists | Actor, object, attempted action, expected and observed result |
Field | Confidential or regulated fields and field-level permission expectations | A field hidden in the UI is not returned or changed through custom code or API paths contrary to policy | Sanitized request and response, field rule, affected role |
Record | Ownership, teams, territories, sharing and partner partitions | A user sees and changes only the synthetic records authorized for that user's relationship | Record ownership and sharing context, cross-role comparison |
Guest | Public site routes and intended public records | A visitor receives only approved public data and cannot infer private records through alternate queries | Route, response shape, sanitized public and private examples |
Integration | Named connected app or service identity and approved business purpose | The identity's reachable data and operations stay within approved objects and records | Grant or account identity, action trace, owner decision |
The useful unit is not “all profiles.” It is a small set of identities that represent materially different entitlements. For example, an internal case agent may need to update a case assigned to a queue, while a partner user may need read access only to cases tied to its own account. A synthetic pair of partner accounts and a synthetic cross-account case make the rule testable without exposing customer data. The signed scope should state who creates these records, how long they exist and who cleans them up.
Figure 2: Object, field and record boundaries must be checked across distinct customer-controlled identities. Source: Salesforce Developers, Protect Your Application from CRUD/FLS Vulnerabilities.
Custom Apex and Lightning: test effective behavior, not labels
Custom code can alter the effective access model. Salesforce's documentation says user-mode database operations enforce sharing, CRUD, field-level and restriction rules; it also describes explicit system-mode operations. Its Lightning Web Components guidance notes an API-version distinction in Apex defaults: version 67.0 and later runs in user mode by default, while version 66.0 and earlier runs in system mode by default. A buyer should therefore ask testers to identify the relevant operation and code version, rather than assuming a single global default (Salesforce Developers, Secure Apex Classes).
Sharing declarations address record visibility, but they do not by themselves establish object or field permissions. The Lightning Web Components documentation says with sharing and without sharing affect record-level security, while object and field controls need their own enforcement. It also notes that authenticated or guest users reach an Aura-enabled Apex method only when the relevant profile or permission set allows access to the class (Salesforce Developers, Secure Apex Classes). That produces a practical test question: does the same restricted identity get a different answer from a custom controller than from a standard UI view?
Prioritize custom data services, Aura-enabled controllers, Visualforce pages still in use, custom REST endpoints and flows that expose high-value objects. Ask for source-assisted review when the customer can provide code. A black-box result can show an access mismatch, but code context often explains whether it came from an intentional privileged operation, missing field enforcement or a sharing decision. The tester should describe the effective path and business consequence without dumping broad production data.
Code review should follow actual entry points, not simply search for a keyword. A class marked with sharing may call another component, and a query may override its operating mode. Conversely, a system-mode operation may be legitimate within a tightly controlled workflow. The question is whether the externally reachable flow honors the approved policy for that identity. Ask the vendor to map each material finding to a named entry point, execution context, data operation and boundary crossed.
Experience Cloud and guest access require their own evidence
An Experience Cloud site changes the audience. Salesforce warns that guest-user read access exposes record data to the public. Its developer guide advises removing sensitive information from unauthenticated responses, warns against guessable record references, and calls for careful response design when code runs without sharing (Salesforce Developers, Give Guest Users Access to Read Records).
The scope should identify every public site hostname and route associated with the customer's account, every guest-available object, the intended public fields and the workflow owner. Tests should compare the intended public record with a synthetic private record and inspect all response formats used by the page, including the browser response and the backing Apex or API call. A page that hides a value visually has not proved that the server withheld it. At the same time, the tester must stay within the customer-owned account and avoid broad enumeration or traffic patterns that could affect the service.
Authenticated partner and customer community roles are different from guests. The same object may have separate partner record-sharing rules, entitlement relationships and custom controllers. Include a minimum of two synthetic partner identities with different ownership, plus a restricted internal identity when the business process crosses staff and partner boundaries. A report should state whether the discrepancy is public exposure, cross-partner access or internal overprivilege. Those are different remediation decisions.
Where a public workflow legitimately creates records, the buyer should agree on safe test records and rollback. The report should distinguish a privacy failure from expected public functionality. Salesforce's guest guidance explicitly describes patterns for controlled create and read flows; the existence of a guest-created record is not itself proof of an issue. The test has to show unauthorized information or action relative to the approved design (Salesforce Developers, guest access guide).
API and integration paths: keep the same authorization model
Salesforce data may leave the org through a connected app or service identity. The customer-org test should name the integration identities and API endpoints whose behavior is in scope. It should establish the expected objects, fields and record population reachable by each identity. Then it should compare results across UI and API paths using controlled synthetic records. The useful finding is an effective access difference with business meaning, not a list of granted scopes without a reachability check.
A high-value example is a service identity intended to synchronize only open support cases. The buyer can create a synthetic closed case containing a sentinel field and ask whether the integration can read it. Another example is a partner-facing API that should return records for one partner account but accepts a record reference belonging to another synthetic account. These are test-design examples, not assertions about any Salesforce default or a particular customer's configuration.
Integrations also bring third-party boundaries. An API call into a customer Salesforce account may be in scope; the vendor's own SaaS tenant or codebase is not automatically so. If the engagement includes a connected app hosted elsewhere, record its owner's authorization separately. Our third-party API integration testing guide covers that broader trust chain. In this SOW, list the exact account, identity, endpoint and permitted action so that an integration test never silently expands to another provider.
For an organization with many Salesforce and other SaaS connections, the enterprise SaaS portfolio scope explains how to group platforms into a program. This Salesforce article is narrower: it asks what evidence a single customer-org engagement must produce.
The SOW that procurement can sign
The SOW should be a table of decisions rather than a promise to “test all Salesforce.” Put the current agreement and service list beside the buyer's own account inventory. The buyer should ask its legal or vendor-management owner to record the answer to the third-party approval condition and the conflicting Salesforce reporting directions. Technical kickoff follows that decision.
SOW line | Required specificity | Acceptance criterion |
|---|---|---|
Authorized property | Purchased Salesforce service, customer org and account identifiers, named Experience Cloud domains | Every tested URL and identity maps to a named customer account |
Third-party authority | Written decision on section 2(c), contract chain, confidentiality and test contact | Approval position is documented before external testers act |
Environment | Production or sandbox, release and configuration comparison, maintenance schedule | Report names the actual environment and any production-equivalence limit |
Identities and data | Internal, partner, guest and integration roles; synthetic records and cleanup owner | Each material access boundary has a positive and negative test identity |
Methods and windows | Manual paths, allowed automation, agreement time window, rate limits, stop rules | Test log distinguishes manual and automated activity and confirms the permitted window |
Findings route | Customer escalation owner and Salesforce channel resolution | High-severity and unexpected cross-account/RCE handling are agreed before testing |
Report | Severity, expected versus observed behavior, sanitized requests and responses, reproduction logic | Findings are usable for remediation; scanner output alone is not the report |
Retest | Remediation owner, changed permission or code path, retest environment | Evidence shows the same identity-path pair now honors the approved rule |
A testing partner should push back on the phrase “cover all roles” unless the buyer supplies a role inventory. The better purchase is representative coverage with a written sampling rationale and explicit exclusions. If the org has thousands of permission-set combinations, the security team should prioritize the combinations that can read sensitive records, invoke privileged custom code or cross external-tenant boundaries. The report then states what was sampled and what remains untested. This is more honest than a coverage percentage detached from the account design.
Ask the vendor how it will keep the test safe. A useful answer identifies test records, rate controls, logging, a named stop contact and a plan for a surprising result. It recognizes that a proof of unauthorized access can be made with a small synthetic record comparison. It also commits to preserve only the minimum evidence needed for remediation and to honor the agreement's confidentiality limits. The vendor should not need a full data export to demonstrate a field-level or record-level failure.
For a custom-code-heavy org, add source-assisted review and a call graph for the most sensitive entry points. For a public Experience Cloud launch, give guest and partner routes more time. For a mostly standard internal deployment, spend more of the test on permission sets, sharing, reports, API access and integration identities. The SOW should explain why the selected mix follows the business exposure rather than distributing effort evenly over every menu item.
What a good report and retest prove
The report should let a CRM engineer reproduce the access decision without guessing. Each finding needs the affected customer-controlled entry point, the test identity, the synthetic record or field, the expected access rule, the observed behavior, the smallest safe evidence, the reason it matters, and a remediation owner. That also aligns with the agreement's Exhibit A requirement for severity, technical detail, reproducibility and relevant requests and responses (Salesforce, Security Assessment Agreement, Exhibit A).
Severity should follow impact in this org, not a scanner label alone. A low-privilege internal user seeing another sales team's benign synthetic note has a different consequence from an unauthenticated route returning regulated customer fields. The tester should explain the affected population, whether the path is public or authenticated, and whether the issue allows read, change or bulk access. The buyer can then align remediation priority with its data classification and business process.
Retest the same identity and path after a fix. If a team adds a field permission but leaves an Apex response unchanged, a configuration screenshot is not proof of remediation. If a code change blocks one public page but an alternate API path remains, the report should say so. A retest record that names the original evidence and the new result is useful audit evidence for the customer's compliance program. Stingrai's human-led testing includes retesting of remediated findings, with every confirmed finding made available to the buyer during the engagement through its reporting workflow.
Stingrai is a CREST-accredited penetration testing provider headquartered in Toronto. For a Salesforce customer-org engagement, its human-led team can focus on authenticated web and API paths, custom business logic and authorization decisions, with two named penetration testers and review by the team lead and engagement partner. The exact Salesforce services, third-party permissions and org boundaries must be agreed in the quote. Stingrai's reports can support a customer's audit evidence and remediation work.
Frequently Asked Questions
Can a customer penetration test its Salesforce org without advance approval?
Salesforce's June 2026 help article says customers may start security assessments without prior approval or pretest notification, but the assessment remains subject to its Security Assessment Agreement. That agreement separately requires prior written approval before the customer subcontracts or transfers its assessment rights or obligations to a third party. A customer buying an outside penetration test should resolve that condition with Salesforce before active work.
What belongs in a Salesforce customer-org penetration test?
The scope should name the purchased service and customer account, then test the customer's object, field and record permissions across representative internal, partner, guest and integration identities. Include custom Apex, Experience Cloud and API routes where those surfaces can reach sensitive records or actions. Record the expected rule for each identity-path pair and prove the observed result with synthetic data.
Can automated scanning run at any time?
No. Salesforce's Security Assessment Agreement restricts all automated testing to Friday 21:00 PST through Sunday 23:59 PST and forbids assessment during a major upgrade or maintenance window. The SOW should identify automated methods and a test schedule that follows the current agreement.
Does a with sharing Apex class prove the org is secure?
No. Salesforce says sharing declarations address record-level rules, while object and field permissions require separate enforcement. Database operation mode and API version also matter. Test the effective response for a restricted identity through each material custom entry point.
How should a report handle Salesforce's differing reporting directions?
The Security Assessment Agreement contains report and urgent-finding requirements, while Salesforce's newer Security Assessments help article gives different contact direction. The customer should resolve the current channel directly with Salesforce and record the result before scope signoff. The technical report should still contain validated findings, severity, reproducibility and relevant request and response evidence as the agreement describes.
Can a sandbox test stand in for production?
Only to the extent its relevant configuration, identities, data model and code match production. A sandbox can support safe synthetic tests, but the report should name the environment tested and any differences that could alter authorization behavior. A production-equivalence review is a buyer acceptance criterion, not a blanket Salesforce guarantee.
Related reading
References
Salesforce, Security Assessments, June 2026.
Salesforce, Security Assessment Agreement, April 2025.
Salesforce Developers, Protect Your Application from CRUD/FLS Vulnerabilities.
Salesforce Developers, Protect Your Application from Sharing Violations.
Salesforce Developers, Give Guest Users Access to Read Records.
Talk to Stingrai
Stingrai can scope a human-led assessment of the customer-controlled Salesforce paths your team needs to validate and deliver findings your engineers can act on. Get a Quote or book a free discovery call.
