Governing Salesforce without holding its data

Salesforce is where mid-market companies run their revenue. Contacts, accounts, opportunities, cases, contracts, health records, financial data — whatever the business trades in, a significant portion of it lives in the CRM. That is precisely why Salesforce is the first system an auditor examines and, for most companies, the one with the thinnest governance record. The system is central enough that everyone treats it as infrastructure. Infrastructure is the last thing anyone thinks to govern continuously.

The audit question is not whether Salesforce is secure. Salesforce's own infrastructure is not the issue — the issue is how the customer org is configured, who has access to what, how that access was reviewed, and what controls exist around the data inside it. Those are customer-side questions. They require customer-side evidence. And for a growing mid-market company with a Salesforce admin stretched across a dozen priorities, the evidence is rarely where it needs to be when the auditor asks.

Enterprise procurement is applying the same standard. A large customer or partner conducting vendor security due diligence will ask for evidence of access control, privilege review, and data governance in your CRM. If your answer is a screenshot from last quarter and a policy document, the deal pauses. If your answer is a continuous, timestamped record of control operation in the system itself, the conversation moves forward. The difference between those two answers is not effort — it is architecture.

01 / What auditors actually ask about a CRM

Auditors following SOC 2 criteria, ISO 27001 controls, or enterprise procurement security questionnaires arrive at Salesforce with a consistent set of questions. The first category is privileged access: who holds System Administrator profiles, who holds custom permission sets with modify-all-data or view-all-data scope, and how recently was that access formally reviewed against an approved baseline. The second category is field-level security: are sensitive fields — social security numbers, health data, payment card fields, salary records — restricted to the roles that have a documented need, and is that restriction verified rather than assumed.

The third category is data export controls. Salesforce makes it straightforward to export the entire contents of an org to a spreadsheet. Auditors ask whether that capability is restricted, who has it, and whether its use is logged and reviewed. The fourth category is third-party application permissions. Every connected app in the AppExchange integration list has an OAuth scope defining what it can read and write in the org. Auditors ask whether those scopes have been reviewed, whether they are current relative to the approved architecture, and whether any connected app has broader access than its function requires.

The fifth category, increasingly prominent in 2025 and 2026, is AI feature governance. Einstein features, Agentforce deployments, and any Salesforce AI capability that reasons over CRM data brings a new scope question: what data does the AI surface have access to, who authorized that scope, and what oversight exists over AI-generated outputs that influence decisions or communications. Auditors are asking this now. Enterprise customers are including it in procurement addenda. The companies that have not thought through their Agentforce deployment in governance terms will face this question unprepared.

02 / The backwards posture: exporting data to prove you protect it

The conventional GRC approach to Salesforce governance is to connect a vendor's platform to the Salesforce API and pull records into that platform for analysis. Who has access to what gets answered by extracting user, profile, and permission set records. Field-level security gets answered by pulling object metadata and field definitions. The appeal is obvious: the GRC dashboard shows a unified view.

The problem is structural. To prove that your org protects customer data, you have granted an external vendor API access to that data. The customer records, account data, and sensitive fields that your access controls are supposed to protect have now left Salesforce and arrived in a third-party system. That system has its own security posture, its own data retention policies, its own breach surface. If that vendor is breached, your CRM data is in scope. If a regulator asks whether customer data is confined to approved systems, the GRC integration is a new answer you did not want to give.

Granting a vendor API access to your CRM to prove you control access to your CRM is not a compliance solution. It is a new compliance problem wearing a dashboard.

For companies handling data subject to HIPAA, state privacy laws, financial regulations, or contractual data handling restrictions, this is not a theoretical concern. The data classification that makes Salesforce governance important in the first place is the same classification that makes extracting that data to a third-party system a serious risk and, in some cases, a violation of the commitments the company has made to its customers. The governance posture must not require the exposure it is trying to prevent.

03 / Evidence at the source

Governing Salesforce without moving its data means collecting evidence of control operation from the system itself, in a form that is independent, timestamped, and verifiable, without any underlying records leaving the org. The access review evidence is not a spreadsheet of user records — it is a hash-anchored record that the review was performed, that the permission sets matched the approved baseline, and that any deviations were documented. The permission set snapshot is not a copy of the data those permissions protect — it is a record of the configuration state at a point in time, signed and stored in the governance system.

This is a meaningful distinction for auditors. The SOC 2 auditor reviewing logical access controls is asking whether the company can demonstrate that access was reviewed and that the review matched the control description. That demonstration does not require the auditor to see customer records. It requires evidence that the review happened and what it found. A timestamped, independently collected record of the review process — tied to the specific permission sets in scope and the approved baseline they were compared against — is what satisfies the control. Customer data is irrelevant to the evidence.

The same logic applies to data export controls and connected app permissions. The evidence that export capability is restricted to named roles is a snapshot of those restrictions, not a copy of the data those restrictions protect. The evidence that a connected app's OAuth scope matches the approved architecture is a record of the scope and the approval, not a sample of the records that scope could access. Collecting that evidence at the source — from Salesforce's own configuration and audit APIs — produces proof without exposure.

04 / Einstein and Agentforce: AI features entering governance scope

Salesforce's AI surface has expanded significantly. Einstein features across Sales Cloud, Service Cloud, and Health Cloud reason over the data in the org to generate predictions, recommendations, and automated actions. Agentforce deployments build autonomous agents that interact with CRM data, trigger workflows, and communicate with customers. These capabilities are useful. They are also a new governance scope that most companies have not mapped.

The governance questions for AI features in Salesforce are a direct extension of the access control questions that already apply. What data scope does the AI feature have? Who authorized that scope? What oversight exists over the outputs — the recommendations surfaced to sales reps, the automated responses sent to customers, the actions taken by an Agentforce agent on behalf of the company? If an AI feature reasons over PHI-bearing objects, that is a HIPAA consideration. If it reasons over financial records, that is a financial data governance consideration. The feature's utility does not change the underlying data classification.

Enterprise customers are already including AI feature governance in their procurement questionnaires. They want to know what AI capabilities are deployed, what data those capabilities can access, and what oversight the vendor maintains. A company that can answer with a continuous record of AI feature configuration, authorized scope, and oversight activity is a company that wins the deal rather than stalling it. A company that has not thought through its Agentforce deployment in those terms will spend weeks assembling an answer that should have been continuous.

05 / What a continuous record changes for SOC 2 and procurement

A SOC 2 Type II audit covers a period — typically six or twelve months. The auditor selects samples from that period and asks for evidence that the described controls operated. If the company produces a point-in-time screenshot from the day before the audit window closed, the auditor asks for more. If the company produces a continuous record of control operation across the full period, with independent timestamps and no gaps, the audit moves efficiently.

The practical difference between those two scenarios is not the underlying quality of the controls. A company with good access controls and no continuous evidence of their operation will have a harder audit than a company with the same controls and a continuous record. The audit finding is not "your controls were bad" — it is "you cannot demonstrate your controls were operating for the period." That finding has the same effect on the audit opinion as a control failure.

Enterprise procurement is applying the same lens at an accelerating pace. Large customers conducting security reviews of their vendors are moving from questionnaire-based assessments to evidence requests. They want to see the governance record, not the governance intent. A mid-market company that governs Salesforce continuously — collecting access review evidence, permission baseline comparisons, and AI feature oversight records at the source, independently, without moving CRM data — can respond to those requests immediately. That is the commercial difference a real governance program produces. Not the appearance of compliance. Proof of it.