Hey everyone! I've been running Fathom Analytics on a few side projects for months and I love how lightweight and privacy-focused it is. Now I want to roll it out to a client project at work, but their security team is (rightfully) cautious about any new third-party tool. They've flagged it for review.
My main talking points are going to be:
* **No personal data:** It doesn't collect IPs, doesn't use cookies, and anonymizes everything. It's GDPR/PECR compliant by design.
* **Data ownership & location:** The data is stored in the EU/US (depending on plan) and Fathom acts as a processor, not a controller.
* **Minimal script footprint:** The tracker is tiny compared to other solutions, reducing attack surface.
I'm planning to show them the script snippet itself:
```html
```
And maybe contrast it with a typical Google Analytics setup to show the difference in complexity and data points.
Has anyone else gone through a formal security review for Fathom? What specific evidence or documentation did your security team want to see? I've got their compliance page and data processing agreement, but I'd love to hear what sealed the deal for others.
~CloudOps
Infrastructure as code is the only way
Great points! I had to do this a few months back. What really helped us was showing Fathom's SOC 2 Type II report - our security team asked for it specifically. Have you pulled that yet?
Also, be ready to explain the 'processor vs controller' distinction clearly. Sometimes that's the sticking point. Good luck
I've been through several of these reviews. Your talking points are solid, but you're missing a key artifact that will be their primary focus: the formal **data processing agreement (DPA)** and its exact clauses.
Yes, Fathom provides a standard DPA, but your security team will want to see if it's aligned with your master service agreement. Specifically, they'll look for terms around breach notification timelines, subprocessor approval rights, and data deletion procedures. Get the signed DPA ready, not just the template.
Also, be prepared to map their SOC 2 controls to your own internal control framework. The SOC 2 report is useful, but only if you can demonstrate which of your security requirements it satisfies. I usually create a simple matrix linking their control objectives to our internal policy IDs.
infrastructure is code
Yes, that DPA point is crucial. I'd add that in our last review, the timeline for *acknowledging* a breach versus actually *notifying* us became a huge point of contention. The standard language was vague.
And that mapping exercise is so true. Our security team doesn't just want the SOC 2 report, they want to know which of our internal risk controls it checks off. I usually just export their SOC 2 Appendix A, add a column for our internal policy reference, and highlight the matches. It turns a complex document into a simple checklist for them.
Your points are good, but the script snippet won't impress a security review. They'll want the concrete artifacts: a signed DPA, the SOC 2 report, and evidence of your due diligence.
Pull the actual breach notification timeline from their DPA and be ready to quote it. "Notifies within 72 hours" is acceptable, "endeavors to notify" is not. Also, run a quick dependency check on the hosted script. Show them there are no external calls to third-party CDNs.
The footprint comparison helps, but it's a secondary concern. Get the paperwork right first.
shift left or go home
Totally agree on the dependency check. That's a concrete step I've done before, and it's a quick win. Just pulling the script via curl or checking the network tab can show it loads directly from Fathom's own domain, no extra third-party calls.
And you're right, the exact phrasing on breach notification is what they'll parse word by word. "Endeavors to notify" would get flagged immediately in our reviews too. Gotta have that firm timeline.
Keep it simple.