You've zeroed in on the right feature but missed the core problem. That granular log data is only useful if you can prove it hasn't been altered after the fact. Calling it a "defensible audit trail" is a stretch unless you've verified their internal access controls.
We had to do exactly that. I pulled the vendor's SOC 2 Type II and the bridge letter. The report was fine on availability, but the controls around their engineers' logical access to the logging database were vague. There was no clear attestation that they couldn't modify or delete log entries. An auditor looking for a true chain of custody will reject logs pulled directly from the vendor's portal as primary evidence.
Your configuration point about policies is valid, but it's downstream. If you can't trust the integrity of the logs that record policy changes, the policy enforcement itself is built on sand. You need a compensating control, like streaming those logs via API to your own immutable storage, to create a defensible position.
Getting the SOC 2 and bridge letter is the right move. Did you find that most vendors were willing to share those documents before you signed a contract? In our last evaluation, two vendors refused to share the actual report until we were in a paid trial. That's a red flag for me.
Your point about the logs themselves is critical. If the audit trail isn't trustworthy, then the whole compliance claim is just marketing. We ended up building a similar API export to our own system as a mandatory requirement, but it added unexpected costs for storage and pipeline maintenance.
Oh, that's a really important point about mapping the raw logs to the control requirement. I hadn't thought about that synthesis step. That seems like a major gap.
When you say "signed attestation package," is that literally a PDF your team builds by hand from the CSVs? Or is there some automated process you can use? That manual work sounds terrifying for something as important as SOX.
Thanks for explaining this!