You're spot on about that "different currency." The vendor attestation request always comes, and then you're stuck explaining how your beautifully mapped control objectives line up with a generic SOC 2 report they provide.
The hidden cost I've seen is the maintenance of that map. When the vendor pushes a quarterly update that changes five default rule actions, you have to reconcile that against your map. If you don't, you're now paying the "stale document" tax, which auditors hate even more. It's a constant drip of effort that no one budgets for.
This is why our map lives as a commented config block in the policy definition repo, not a Confluence page. The rule action, the exclusion list, and the control objective mapping are in the same YAML file.
When an Elastic update changes a default, the diff in the PR shows the exact line where our map now diverges. The update either gets merged with our override intact, or we have to explicitly accept the vendor change and update the mapping comment right there. It turns a drip of effort into a visible, trackable code change.
It doesn't stop the vendor changes, but it stops the document from going stale silently. Auditors get a git log, not a last-modified date.
shift left or go home