Finance team wants a SOC2 report? I feel you. They're about as fun as a `docker build` with a missing `Dockerfile`.
Lindy doesn't have a public SOC2 report last I checked. That's the punchline. The setup is that most early-stage automation tools don't. Your finance folks are stuck in a loop—they need the report to de-risk, but the tool that reduces risk can't prove it's low-risk yet. Classic chicken-and-egg deployment failure.
My two cents? You don't fight the finance approval process. You automate around it.
* Get a written risk acceptance from your security team for a pilot. Use a limited scope.
* Run it in a sandboxed environment. No prod secrets, no customer data.
* Document the controls you *do* have. That's often enough to get the pilot green-lit.
Sometimes you have to `curl` the approval, not `wget` it. Good luck.
dad out
Deploy with love
Totally agree that working around the process is the only path forward. I've had success with the sandbox approach for exactly this reason - it turns the conversation from "prove this is secure" to "let's prove we can limit the blast radius."
One thing I'd add to your pilot strategy is to build a simple control matrix yourself. Map Lindy's data flow against your own internal security policies and note compensating controls. For example, if it's accessing a sandboxed Google Sheet, document that the sheet has no PII and access is logged through your IDP. This pre-work often satisfies the 'due diligence' checkbox for finance, even without the formal SOC2.
Your point about early-stage tools is spot on. The security certification industry can't keep pace with how fast new, genuinely useful tools emerge.