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.
Getting that current subprocessor list directly from legal/compliance is key, as user946 noted. We had to push our sales rep to make that introduction, but the compliance team provided it quickly once we were in the right channel.
On the DPA, ours was standard and aligned well. The only clause we needed to discuss was around the notification period for new subprocessors. Their standard terms were reasonable, but we requested a slightly longer window to accommodate our internal review cycle, which they accepted without issue.
—HR
A longer notification window is a sensible ask. We also pushed on the method of notification. "Check our website monthly" wasn't acceptable; we got them to commit to email alerts to a compliance DL. Otherwise, you'll miss it and the clock's already ticking.
Prove it.
The documentation discipline you describe is its own form of technical debt, and it often scales poorly with organizational growth. We've found that teams can maintain it initially, but after a few vendor schema changes and personnel turnover, the Confluence page becomes a fragmented artifact. The audit trail breaks when someone forgets to archive the old screenshot or links to an expired S3 bucket.
This is where a git repository for compliance artifacts, with a strict commit message convention, can offer a more durable version control mechanism than a wiki page. You commit the new schema screenshot and mapping CSV, with a diff-able changelog in the commit history that auditors can still follow. It trades one form of discipline for another, but git's inherent structure around changes reduces the risk of incomplete updates. The key is making the repository's README the single source of truth for the procedure itself.
Obtaining the DPA and subprocessor list is straightforward, but the critical step most teams miss is validating that the DPA's defined data processing activities map accurately to the data flows in the actual product. Fathom's DPA will generically cover "conversation intelligence services," but you must explicitly confirm this includes derived data like AI-generated summaries and sentiment scores, not just the raw audio/video streams. We found a discrepancy where their subprocessor list for analytics wasn't initially inclusive of the ML inference pipeline.
Regarding the list, insist it's provided as a machine-readable JSON feed or via an API endpoint, not just a PDF. This allows you to automate periodic checks against your approved vendor registry. Their legal team should accommodate this; if they push back, it's a red flag about their operational maturity for compliance automation.
The DPA's the easy part, honestly. They'll send you a pdf that ticks all the generic boxes. The gotcha is that "standard SOC2 requirements" phrase - there's no such thing. Your auditor's interpretation of "adequate notice" for new subprocessors is likely different from theirs.
Insist on that machine-readable subprocessor list, like user1330 said. A PDF is a compliance liability waiting to happen; you can't automate a diff check against it. If they balk, ask them how they track *their* vendors' subprocessors. It usually gets a product manager on the call real quick.
And don't just map the list to your registry. You need to trace each one to a specific data action in their product. Where does the transcription happen versus the sentiment analysis? We found a third-party NLP provider on their list that wasn't mentioned anywhere in the data flow diagrams.
Trust but verify.
Getting the DPA and a list is the paperwork exercise. That won't save you when their sentiment analysis model swaps providers and starts sending meeting summaries through a new subprocessor not on your approved list six months later. The "standard" DPA is useless if their product team treats the ML pipeline as an implementation detail they can change without considering your compliance overhead.
Your real starting point is getting engineering commitment, in writing, on their change management process for subprocessors related to core data actions. If they can't articulate how a new NLP vendor gets added to the list *before* it touches prod data, you're building your compliance on a foundation of hopes and PDFs.
"Standard SOC2 requirements" is a red flag. There's no standard, only your auditor's opinion versus theirs. A signed DPA that aligns is meaningless if the definitions are vague.
Getting the list is step one. The real fight is ensuring their product roadmap, especially for AI features, is bound by the same change controls. If they can swap a model provider on a Tuesday, your DPA is fiction.
Ask them to walk you through a recent change to their processing pipeline and show you the ticket that updated the subprocessor list. If they can't, you know what you're buying.
Your stack is too complicated.
>show you the ticket that updated the subprocessor list
This is the only reliable signal. We audit this by checking the commit hash in their release notes against their infosec ticketing system. If the subprocessor update ticket isn't linked to that hash, their change control is theater.
The ticket must include the data impact assessment. Adding a new NLP provider for summaries is a material change, not a routine deployment.
Numbers don't lie.
Exactly. That generic "conversation intelligence services" clause is where they'll hide new AI pipelines.
We map every subprocessor to a specific AWS service or API call in our Terraform modules for the integration. If Fathom can't tell you which external API endpoint handles the sentiment scoring, you can't map the data flow. Their DPA becomes a checklist item, not an operational control.
Machine-readable list is non-negotiable. We pipe that JSON directly into our compliance scanner. If it's not in the feed, the deployment fails.
—cp