My team is eager to adopt Read AI for meeting productivity and analytics, but our security and compliance team has flagged it for review. The initial concerns are standard: data handling, compliance certifications, and vendor risk.
I'm compiling a due diligence package. From a procurement and FinOps standpoint, I believe the key is to address security concerns while also framing the risk in the context of our existing toolchain. My approach is to compare its posture to already-approved vendors like Gong or Otter.ai, focusing on:
* **Data Processing Addendums (DPA):** Does Read AI's DPA align with our standard clauses? Specifically, data retention periods, subprocessor notification, and data deletion workflows.
* **Certifications:** SOC 2 Type II and ISO 27001 are baseline. I'm looking for explicit evidence these are current.
* **Data Residency & Encryption:** Where is meeting audio/text processed and stored? Is encryption at rest and in transit clearly defined? Does it align with our regional requirements?
* **Subprocessor List:** A transparent, publicly available list is a strong positive indicator. I'll compare their infrastructure providers (e.g., AWS, Google Cloud) against those used by our other approved SaaS tools.
Beyond compliance checkboxes, I plan to present a total cost of ownership analysis that includes the *risk cost* of *not* having a governed, enterprise-grade tool. The argument will be that if we block Read AI, teams will likely resort to unvetted, shadow IT alternatives with far worse security postures.
Has anyone successfully navigated a similar security review for Read AI or a directly comparable tool? I'm particularly interested in any specific contractual terms you negotiated or unique security clarifications you received from their team that aren't in their public materials.
Trust but verify. Then renegotiate.
Your "compare to already-approved vendors" tactic is the most powerful part of your package. I'd add a specific, tactical step: pull the security review docs from when Gong/Otter were approved. Find the exact language your security team used to sign off on *those* DPAs and subprocessor lists, then mirror it when presenting Read's.
One caveat - don't just assume their AWS region usage is identical. A quick check of their subprocessor list vs. Gong's could reveal a different data center locale that might be a deal-breaker for your compliance folks. That's often the hidden snag. Good luck, this is the right way to frame it!
Oh, that's a good point about checking the subprocessor list. I've been trying to learn AWS regions myself for a project. Could a vendor using something like `eu-central-1` instead of `us-east-1` really block an approval? Our security docs are kinda vague on that.
Also, where do you even find those old review docs for Gong? Is that in Confluence or some internal security portal? I've never had to do this before 😅