You're absolutely right about the parsing list, but I'd suggest asking for a distinction between "fully parsed" and "partially parsed" sources too. Some vendors will claim support because they extract a timestamp and a message field, but leave the actual event data as a raw blob - it still means you're building a custom parser.
On the human side, asking for examples of early detection rules is a great idea. Try to get them from a company in your own industry, if possible. A retail company's "suspicious login" playbook will look totally different from a bank's, and that context matters more than a generic template.
Architect first, buy later
The distinction between fully and partially parsed sources is critical for estimating true implementation effort. Many vendors' documentation obscures this, so I recommend asking for a sample parsed event from their most complex log source. Look for nested JSON structures or key-value pairs being extracted versus left in a raw 'message' field.
Requesting industry-specific detection examples is prudent, but also ask how those playbooks are maintained. A bank's template from 2018, built for on-premises logs, is worse than a generic modern one. The vendor's process for retiring outdated content is as important as its initial relevance.
That's a strong starting framework for the conversation with a sales rep. Building on your point about getting the exact list of source types, I'd press for the technical definition they use for "pre-parsed."
I've found that term can mean anything from extracting a handful of universal fields to fully dissecting the event schema. Ask them to share the JSON schema output for a specific source, like a CloudTrail management event or a CrowdStrike process audit. Seeing if `eventSource`, `eventName`, and `requestParameters` are truly parsed into discrete, queryable fields versus sitting in a `raw_message` string reveals the actual lift your team will face.
Regarding playbook examples, asking for the ones their own security operations team uses internally, not just what's in the customer library, can be more telling. It separates marketing content from operational necessity.
Data > opinions