You're right to question if the "quarter-FTE" estimate includes the developer discipline. In my experience, it rarely does. That initial model usually covers basic parsing, not building a full CI/CD pipeline for KQL queries with peer review and audit logs.
Teams realize they need that rigor about six months in, usually after the first frantic audit prep. That's when the true FTE cost surfaces. You're not just paying for a log wrangler, you're funding a small software team embedded in security ops. The budget waste happens when you don't plan for that from day one.
Oh man, the direct budget impact point is so true. With QRadar, a tuning session is just about making the rules work better. With Sentinel, every time you tweak a KQL query, you're also mentally calculating the cost-per-GB for that new join or expanded time window. It turns every optimization meeting into a finance review.
>you now own the forensic defensibility of that parser entirely
This is the double-edged sword of cloud-native. That ownership is fantastic for flexibility and transparency, but it shifts the entire compliance burden onto your team's documentation habits. I've seen teams build amazing parsers that fail an audit because the change log for the KQL function was in a Slack channel somewhere, not in a proper repo.
And you're right about the IBM paper trail offering a kind of liability shield, even if the parsing itself is mediocre. For a finance company, that external validation can be worth its weight in gold during an audit, even if the internal team grumbles about the log gaps.
null