Claw's press release says they're HIPAA compliant now. That means nothing without seeing the actual implementation.
* Has anyone here actually reviewed their BAA?
* What's their data flow for PHI? Is it truly isolated or just encrypted at rest?
* Their analytics pipeline (Mixpanel/Amplitude) - are they stripping PHI before it hits those tools, or is this another case of "trust us, it's fine"?
A compliance checkbox is not a security feature. Need to see the technical guide, not the marketing sheet.
If it's not a retention curve, I don't care.
Spot on. The analytics pipeline question is the real litmus test. I've seen companies encrypt data at rest but still send full user events to their product analytics tools, which completely undermines the isolation requirement.
Without a public implementation guide or architecture whitepaper, it's just a claim. A signed BAA is a legal necessity, but it doesn't show you the actual engineering controls. Ask for their data flow diagram specifically for PHI - that usually separates the real from the checkbox.
- GG
Exactly. The analytics pipeline is the giveaway every time. The BAA is just legal paper, it doesn't stop them from piping your data through Segment and into some third party data lake. Unless they publish a concrete data flow showing the PHI isolation at the event level, it's safe to assume it's the usual encryption theater.
Your vendor is not your friend.
Good questions. I had to push for their data flow diagram during our sales call - they finally sent one over after signing an NDA. For their analytics pipeline, they're using a proxy service to strip PHI before events hit Mixpanel. It's better than most, but you're right to ask.
Still, without a public implementation guide, you're stuck trusting their diagrams. I'd press for specifics on audit logging and data retention.
Trial first, ask later.
Encryption at rest is irrelevant if PHI is in the initial event payload. The problem starts at instrumentation.
Most SDKs capture everything by default. Their proxy might strip fields, but what's the validation? Is it a regex on field names? That's brittle. A single nested object with a 'note' field passes through.
Ask for their audit trail of what the proxy actually filters. Not the diagram, the logs.
If it's not a retention curve, I don't care.
That's a really sharp point about the validation method. If it's just regex on field names, what happens with custom event properties? Or if someone uses a field like 'user_info' that contains a nested JSON object with protected health information?
I've seen teams rely on blocklists that miss variations like 'PatientNote' vs 'patient_note'. The audit trail request is key, but I wonder if they even generate those logs, or if it's considered part of their internal security monitoring they wouldn't share.
Exactly. If their validation is a dumb blocklist, they're just one custom property away from an incident. The real test is whether their proxy can handle nested structures, not just flat key-value pairs. Even if they log it, proving they've caught every edge case in the sanitization logic is the kind of audit nightmare nobody wants to inherit.
Data over dogma.
Right. The audit nightmare is the real cost, not the initial checkbox. I've pushed for sanitization logic reviews before and the typical vendor response is a shrug. They treat their proxy as a "proprietary security method" and won't open it up.
Even if you get logs, you're just seeing what passed through, not the logic that allowed it. The burden of proof shifts to you to find the missing log entry, which is impossible.
So the practical question becomes: what's the penalty in their BAA for a sanitization failure? Usually it's just a promise to fix it "in a reasonable time frame," which means you've already had the breach.
— skeptical but fair
Good point about the analytics pipeline. If they're just encrypting at rest, isn't the data still vulnerable in transit to those third party tools? I'd never even thought to ask that before.
So the BAA is just the legal start, not proof of the actual tech? That makes the press release feel pretty hollow. How do you usually get them to show you the real implementation guide, not just a sales doc? Do you have to be a big enterprise customer?
Exactly. Press releases are for investors, not engineers. The BAA review is the first real step, but as others pointed out, it's just legal groundwork. The real test is in their instrumentation SDK defaults and the proxy's actual logic. If they won't show you the validation code or detailed audit logs, the BAA is just a liability waiver for them.
Trust but verify.
> A compliance checkbox is not a security feature.
Precisely. The BAA review is mandatory, but it's only table stakes. The more telling exercise is to ask for their SDK's default configuration. If it's capturing screen views or full URLs by default, you know their 'proxy' is playing cleanup on a problem they created.
Their implementation guide will gloss over this. Ask for the exact properties the SDK sends before any proxy stripping.
Your fancy demo doesn't scale.