Skip to content
Notifications
Clear all

How do I convince my security team it's safe to use?

3 Posts
3 Users
0 Reactions
4 Views
(@crm_hopper_2027)
Reputable Member
Joined: 2 months ago
Posts: 133
Topic starter   [#9840]

Ah, the annual security review. A ritual more predictable than my migration scripts. You've found a tool—Fathom, in this case—that actually seems to improve rep productivity and capture insights from calls without manual note-taking. The business case is solid. Then you send the link to your security team and watch the ticket immediately balloon with requests for SOC 2 Type II reports, data flow diagrams, and penetration test summaries.

I’ve been through this dance with Gong, Chorus, and now this. The security team’s job is to say "no," and your job is to make saying "yes" less terrifying for them. It’s not about blind trust; it’s about assembling an artifact trail that would hold up in a low-stakes internal audit.

Here’s the cynical playbook I used last quarter to get a similar call intelligence platform through the door. Your mileage may vary, but the principles are portable.

**First, acknowledge their actual concerns (they aren't being difficult for fun).**
* **Data Sovereignty & Storage:** Where is the audio/video/transcript data actually stored at rest? Fathom’s documentation should specify this. Is it siloed by region? Can you mandate a specific region (e.g., EU data in EU data centers)? This is often the biggest sticking point.
* **Transit Encryption:** TLS 1.2+ is table stakes. They’ll want to see the word "encryption in transit" explicitly.
* **Access Controls & Authentication:** How does Fathom integrate with your IdP (Okta, Azure AD)? Is SSO mandatory, or just "available"? The goal is to ensure there’s no bypass of your MFA policies. Also, what’s their internal employee access model? Do their engineers have routine access to customer call data?
* **Data Processing & Vendor Subprocessors:** This is the rabbit hole. You need their list of subprocessors (AWS, Google Cloud, transcription services, etc.). Your security team will cross-reference this against their own approved vendor list.
* **Data Retention & Deletion:** What happens when you delete a recording in the app? Is it truly purged from backups, or is it "soft deleted"? What’s their default retention period? Can you set a global org-wide policy?

**Second, do their homework for them.**
Don’t just forward a security@fathom.ai email. Create a condensed, internal-facing document that collates the answers. Structure it like a poor man’s security assessment:
* Link directly to Fathom’s security page and compliance certifications (SOC 2, GDPR, etc.).
* Extract the relevant snippets from their Privacy Policy and Terms of Service regarding data handling.
* Screenshot the admin settings where you can enforce SSO and configure data retention.
* Propose a **limited pilot** with a hardened configuration: SSO mandatory, integration only with the CRM (no external note-taking apps), and a 90-day auto-delete policy for all recordings. This limits exposure.

**Third, address the elephant in the room: the recording itself.**
The legal and compliance teams might get looped in. You’ll need a clear, communicated policy for reps to inform participants they are being recorded. Fathom provides tools for this (disclosure sounds, in-app notifications), but you must mandate their use. This isn't a technical security issue, but it will become your security team's problem if it's mishandled.

Ultimately, you’re not convincing them it’s "safe"—nothing is. You’re demonstrating that the risk is understood, mitigated where possible, and acceptable relative to the operational gain. Present it as a controlled experiment with off-ramps, not a permanent, sprawling deployment. And for the love of all that is holy, get any approved configuration in writing. You’ll need it for the post-mortem when you evaluate their competitor in 11 months.



   
Quote
(@cost_observer_42)
Estimable Member
Joined: 1 month ago
Posts: 122
 

Hold on, you're assuming they'll even read the vendor's documentation. Every time I've provided a data flow diagram from the source, security counters with "but that's their marketing, not their *actual* infrastructure." They want an independent audit trail, which most vendors won't hand over unless you're a seven-figure client.

You have to start with their own past approvals. Find a tool they already blessed that has a similar data model. If they approved Gong for call recording, use that as the precedent. The conversation becomes "why is this different?" instead of starting from zero. It's the only way to move faster than their default "no."


cost_observer_42


   
ReplyQuote
(@julianp)
Estimable Member
Joined: 1 week ago
Posts: 55
 

You've nailed the core problem, but the precedent trick has its own pitfalls. Security teams are masters of moving goalposts. If you use Gong as your precedent, they'll immediately point out all the extra concessions they extracted for that deal - the expensive enterprise contract addendums, the dedicated instance, the pen-test clauses you probably don't have budget for with Fathom.

Your move then becomes a negotiation to match those terms, which is exactly what the vendor wants. You're not arguing for safety, you're arguing to spend more money to achieve the same "blessed" status. The conversation shifts from "is this safe?" to "how much will you pay to make us comfortable?" which is a much worse starting position.


If it's free, you're the product. If it's expensive, you're still the product.


   
ReplyQuote