How do I get started with Fathom in a SOC2 environment?

crm_hopper_2026 · 2026-07-26T10:17:33Z

In our ongoing evaluation of conversation intelligence platforms for our revenue operations team, Fathom has emerged as a strong contender, particularly for its seamless integration with Zoom and Google Meet. However, our organization operates under a SOC2 Type II compliance framework, which introduces a significant layer of complexity to any new software adoption. My standard methodology for platform evaluation mandates a thorough security and data governance review before any pilot can be sanctioned. I am initiating this thread to gather concrete, procedural insights from other members who have navigated a similar path. My preliminary research and vendor questionnaire have surfaced several key areas of focus, but I am seeking the nuanced, practical experience of the community. My primary concerns are as follows: * **Data Residency & Subprocessor Vetting:** Fathom's reliance on AWS us-east-1 is acceptable, but we require a complete and current list of subprocessors to undergo our legal team's standard review. Has anyone successfully obtained a signed Data Processing Agreement (DPA) that aligns with standard SOC2 requirements? Were there any non-standard clauses Fathom required? * **Access Controls & Audit Trails:** For compliance, we need to demonstrate strict control over who can access recorded calls and generated notes. How granular are Fathom's internal role-based permissions? More importantly, does the platform provide administrator-level audit logs that detail user access (e.g., "User X viewed call Y at Z time") that can be ingested into our SIEM? * **Data Retention & Deletion Workflows:** Our data retention policy requires the ability to automatically purge records after a set period. Can retention rules be configured at the workspace or user level within Fathom? Furthermore, what is the practical process for a bulk deletion request to comply with a right-to-be-forgotten erasure, and what is the typical fulfillment timeline? * **Integration Security:** We intend to push summaries and highlights into Salesforce and HubSpot. The OAuth flow is clear, but we need to verify the principle of least privilege. What specific permissions/scopes does Fathom request for its Salesforce managed package? Have there been any issues with token handling or unexpected API call patterns that could trigger our security monitoring? I am less interested in general assurances and more in the specific steps, documentation, and potential friction points you encountered. For example, was the security questionnaire response from Fathom comprehensive, or did it require multiple follow-ups? Did you conduct a penetration test on the API, and if so, were there any notable findings? Our goal is to establish a compliant pilot for the sales team within the next quarter, and a clear understanding of these logistical hurdles is critical for my project timeline. Any shared experiences, especially regarding the negotiation of security terms or the setup of compliant workflows, would be invaluable.

Page 2 / 2 Prev

Fathom Reviews

Last Post by emilyk22 1 hour ago

16 Posts

16 Users

0 Reactions

2 Views

RSS

emilyk22

(@emilyk22)

Estimable Member

Joined: 2 weeks ago

Posts: 105

28/07/2026 11:04 pm

Your point about the Confluence and spreadsheet method being transparent for auditors resonates. We followed a similar manual path initially.

The hidden cost we discovered wasn't the procedure itself, but version control. When an API schema updates, you have to meticulously archive the old screenshot, update the spreadsheet, and document the change rationale in the same Confluence page to maintain the audit trail. That process log became as critical as the mapping.

It creates a different kind of maintenance tail, one based on documentation discipline rather than code. Some teams are better at that than others.

Support is a product, not a department.

ReplyQuote

Page 2 / 2 Prev