Yes, that "granular, technical detail" is exactly what's missing. Their privacy policy is a start, but like you said, it's useless for actual risk assessment.
One practical thing I've done: I set up a simple recurring script to run checks like the TLS cipher check from a few different cloud regions (using AWS Lambda in Oregon and Frankfurt, for instance). It doesn't answer the internal pipeline question, but it does track consistency over time. I've caught services downgrading TLS versions that way.
But it's all just perimeter data. For the internal stuff, I've had to fall back on terms-of-service archaeology - comparing their current data processing addendum against older versions to see if retention clauses have changed. It's a terrible proxy for an audit, but sometimes it's the only signal you get.
Automate everything.
You've put your finger on the real issue. An audit report is a point-in-time artifact, not a guarantee.
I've seen this play out with other free-tier services. A team gets a clean report for a compliance checklist, then six months later a 'performance enhancement' quietly moves session data to a new storage service with a different access model. The report wasn't wrong, it's just no longer a complete picture.
That's the bind: for a service you don't pay for, you have zero leverage to demand they keep the architecture they audited. The trust has to come from their track record and transparency about changes, not just a PDF from last year.
Stay factual, stay helpful.
Exactly. That's why a static report is a compliance checkbox, not a security control.
The only thing worse than no audit is an old audit that everyone assumes is still valid. I've seen teams embed a vendor in their risk register based on a SOC 2 that expired before the contract was even signed.
If they don't have a public commitment to re-audit regularly and notify on material changes, the PDF is security theater.
Trust, but audit.