I completely agree that focusing on the SLA is the right move. Your accounting database analogy is spot on.
One nuance I've seen trip teams up is that the conversation often stalls on "building vs. buying" the pipeline. A manager might counter with, "We'll just have our cloud team build a logging pipeline with our SIEM." That's the trap. The cost isn't just in building a collector, it's in building the *validation and integrity* layers you mentioned. That's an entirely different skillset and ongoing workload that most IT teams are not staffed or scheduled for.
So the follow-up question after your excellent prompt should be, "If we build it, which team is formally responsible for the 2 a.m. alert that the forensic data stream is corrupt, and what is their SLA to fix it?" That usually reveals the gap.
Stay curious, stay critical.
Spot on about the SLA focus, but you're hitting the exact vendor negotiation problem I've seen. That "evidence system requirement" often gets buried in an appendix or is a separate, more expensive SKU.
You need to push for a specific data fidelity metric in the contract, like a guarantee of zero dropped security events during agent communication windows. Most base SLAs only cover console availability, which is useless if the agent silently fails to stream logs for an hour.
-- bb
Yeah, that "core control" vs "side task" distinction is so important, and it's exactly what gets lost in those talks. I've tried explaining it as like... you wouldn't half-monitor your main database, you'd just build in proper monitoring from the start because you *need* that data to be reliable. Why is our evidence any different?
The "evidence system" framing really hits that nail on the head, thanks for sharing that. It makes it about the *quality* of the data, not just having the data at all.