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

Getting the subprocessor list and DPA wasn't the blocker for us, they provided those within a week of opening the request. The real time sink was internal.

Our infosec team had a dozen follow-up questions about their encryption key management, specifically around key rotation schedules and access logging for their KMS setup. Fathom's support was decent, but each round of Q&A added about 3-4 business days to the review.

Make sure you get the most current subprocessor list directly from their compliance page, not from a sales rep. We got an outdated one first. The DPA was standard, no red flags. Your legal will probably be okay with it.

The bigger question you didn't ask, but will hit you next, is about deploying their Zoom integration in a SOC2 environment. It requires a specific OAuth scope that our compliance officer needed to pre-approve. That took another two weeks internally. Start that conversation now.

Thanks for the heads up on the OAuth scope issue. That's not something I would have thought to check.

When you say your team needed to pre-approve the scope, was it mainly because it was a new third-party app in general, or were there specific permissions within Fathom's requested scope that raised flags?

Our infosec is pretty strict about data exfiltration, so I can see them getting hung up on something like "recordings:read".

Oh, recording scopes were definitely the main event for us. It wasn't just about adding a new app.

Our internal policy triggers a full review for any scope requesting *persistent* access to recordings data, especially read/write. The `recordings:read` and `recordings:write` scopes got flagged immediately. We had to provide a written justification for why a third party needed programmatic access to all historical and future recordings, not just metadata.

We ended up getting approval, but with a new conditional rule: we had to implement a quarterly audit of the Fathom app's activity logs in our Zoom admin console. It was an extra step our infosec added to monitor for any anomalous download patterns. Maybe your team has a similar policy?

That quarterly audit rule is smart. We got a similar one, but ours is monthly for the first six months. The admin console logs only show *that* Fathom accessed a recording, not *which* user's meeting it was for. Our compliance team accepted that, but they made us add a correlating internal log review to match Fathom's API calls to our own user IDs. It's a manual CSV dump and pivot, takes an hour each time.

If your team is strict on data exfiltration, push them to define what an "anomalous pattern" actually is. We spent two weeks debating thresholds before they'd sign off.

Your point about defining the anomalous pattern threshold is crucial. That two week debate you mentioned is a recurring cost many teams don't budget for, and it's rarely documented. We institutionalized a standard operating procedure from that exact scenario.

We now require our security team to provide, in writing, the specific log field, the exact threshold (e.g., "more than 25 API calls to `recordings:read` in a 5-minute period from a single service account"), and the escalation path *before* the vendor review is closed. This shifts the burden of operational definition onto the policy owners and prevents open ended, moving-target requirements that stall procurement.

The manual CSV correlation you're doing for an hour each month is another hidden cost. I'd challenge the value of that exercise if the admin logs only show app-level access. You're likely just creating a mapping for its own sake, not for a control that can trigger an actionable alert.

Good to see someone else following a proper methodology with a security review first. You're right to focus on the DPA early, as that often becomes a critical path item.

Regarding your specific question about a signed DPA aligning with SOC2 requirements, yes, they provided one that was acceptable. It included the standard clauses for confidentiality, purpose limitation, and subprocessor obligations. However, there was a notable point of negotiation around audit rights. Their standard DPA referenced a right to audit only through provision of a current SOC2 report, which is common, but our legal pushed for explicit language that they would notify us of any material changes in their control environment between report cycles. Fathom agreed to add that.

For the subprocessor list, insist on getting it via a secure link from their compliance or security team, not as an email attachment. We found that the list hosted on their trust portal was updated more frequently than the PDFs floating around sales engineering. The vetting itself was straightforward, but pay close attention to any analytics or data enrichment subprocessors they use; that's where some of our compliance team's questions were focused.

The `recordings:read` scope was indeed the primary trigger, but our deeper technical review flagged the `phone:read` scope as a potential vector. Granting programmatic access to call detail records introduced a separate data lineage that our data governance model wasn't prepared to map automatically.

We ended up having to model that data flow separately in our compliance documentation, which added another week. The lesson was to audit *all* requested scopes, not just the obvious ones for core functionality.

That's such a good catch on the `phone:read` scope. It's exactly the kind of secondary permission that slips through when you're hyper-focused on the main data type, like recordings.

We ran into a similar snag with a different integration, where a `user:read` scope pulled in organizational data that wasn't covered in our initial data mapping. It created a whole new category of PII we had to account for in our vendor risk assessment.

Your point about auditing *all* scopes is spot on. I've started adding a step to our checklist: "For each requested OAuth scope, define the exact data object it exposes and its classification (e.g., PII, internal, public)." It feels tedious but saves so much rework later.

Regarding a signed DPA, yes, they'll provide one. The one point you might need to negotiate is around audit rights notification between SOC2 report cycles, as others have mentioned. That came up for us too.

On the subprocessor list, I'd stress getting it directly from their legal or compliance team via your official request channel, not from your account rep. We found the sales-provided list was a version behind, and our legal review had to restart. Once we got the right one, the vetting was straightforward, but that misstep cost us a week.

The checklist step you propose is essential, but its effectiveness hinges entirely on the platform's API documentation being precise. I've found many vendor docs group disparate data objects under a single scope label, like `user:read`, without enumerating all fields. The classification then becomes guesswork.

You must cross-reference the scope with the actual API response schema. We had to script a call to the endpoint with a dummy service account and map the returned JSON to our data classification matrix. Only then did we realize a seemingly benign metadata scope included indirect identifiers that changed its PII status.

This extra verification layer adds time, but it prevents the compliance rework you mentioned.

Absolutely. The "cross-reference with actual API response" step you describe is critical, but it introduces a hidden operational cost if you're scripting this per-integration. For any team managing multiple vendors, that time compounds.

We automated a piece of this by building a lightweight internal service that takes a service account token and an endpoint, then runs the call and flags fields against a standard internal data classification dictionary. It doesn't solve the initial mapping, but it standardizes the verification and creates a reusable artifact for audits. The catch, of course, is maintaining the classification rules as schemas evolve.

Your approach with that internal service is smart. I've seen similar attempts, and the maintenance of classification rules always becomes the sticking point. You can end up in a loop where updating the rules for one vendor's schema change breaks the flagging for another.

There's also the risk of that service itself becoming a compliance artifact that needs its own controls. Did you have to get it reviewed as part of your internal tooling policy?

Manual CSV correlation for an hour each audit cycle is brutal. We had that same friction, but our security team eventually accepted using Looker to build a dashboard that joins Fathom's audit log export with our internal user directory via a scheduled query. It's still a manual export from Fathom, but the join and pivot is automated.

We also had to define an anomalous pattern. Their threshold ended up being >10 distinct meetings accessed in a 5-minute window without a corresponding internal support ticket. Setting that baseline was the real time-sink.

You've hit the nail on the head about that service becoming its own compliance artifact. That's the trap every "let's automate compliance" project falls into, building a shiny new shadow system that ironically needs its own SOC2 controls and change management process. Suddenly you're writing audit narratives for the tool you built to write audit narratives.

We skipped the internal service route entirely for that exact reason. We went for the boring, slightly painful path: a documented manual procedure in Confluence, with screenshots of the raw API output and a shared spreadsheet mapping fields to classifications. It passes the auditor's sniff test because it's transparent and repeatable. It's slow, yes, but it doesn't create a maintenance tail that rivals the original problem.

The real question is whether you're automating for efficiency or for audit coverage. If it's the latter, you better be ready to treat your helper tool as a production, compliant system.