Learn
What you're actually paying for, in plain English.
Short explainers for Cortex XSIAM, written from your side of the table and grounded in the current Palo Alto Networks public docs and the Cortex marketplace. The vocabulary your partner assumes you know, the patterns the engine flags, and the negotiation language that fits each one. Each lesson cites its source and is dated.
What you can learn about
Every line of your Cortex XSIAM quote, in plain English.
Detection content
3 lessonsOut-of-the-box rules, correlation logic, and what's a deploy versus a project.
Data sources
3 lessonsMarketplace integrations, broker VM, parsers, and which work counts as engineering.
Playbooks
2 lessonsXSOAR templates, automation work, and where bespoke authoring is real value.
Platform configuration
1 lessonTenant setup, RBAC, alert routing. The day-one work that has docs and a checklist.
Analytics versus rules
1 lessonWhy correlation rules and ML analytics are different products, and how reps blur them.
Dashboards and widgets
1 lessonSearches, widgets, and dashboards. Almost always DIY-with-patience.
Services scoping
2 lessonsHow to read a deployment SOW: what's bundled, what's DIY, and what's worth full rate.
Licensing and SKUs
2 lessonsTier mapping, credit-based ingestion, retention, and the math behind the line items.
Correlation rules and Analytics rules are not the same product.
Buyers often pay for both because reps blur the line. Correlation rules are deterministic XQL queries you write or import. Analytics rules are platform-shipped detections built on machine learning. They solve different problems.
Widgets and dashboards: almost always DIY-with-patience.
Cortex XSIAM ships predefined widgets, a Widget Library, and a dashboard builder with role-based access. Custom widgets use XQL queries or scripts. Most of the value can be built by your team in a workshop, not by a multi-week PS engagement.
If your log source is in the marketplace, you're not paying for parser work.
Palo Alto Networks runs a marketplace of pre-built integrations. If your source is in there, the parser is one click. Don't pay engineering hours for it.
Parsing rules: real engineering, but only sometimes.
Cortex XSIAM ships default parsing rules and an editor for writing custom ones in XQL. Most ingestion does not need bespoke parser work. The cases where it does are specific and worth full rate.
How parsing actually works in XSIAM: INGEST, XDM, raw datasets, and the data flow.
Every log byte that lands in your XSIAM tenant takes a specific path: collected by Broker VM or marketplace integration, transformed by parsing rules, normalized into XDM, and stored in the Cortex Extended Data Lake. Knowing the path makes it obvious which work is configuration and which is engineering.
OOTB rules enablement is a switch flip, not a project.
Cortex XSIAM ships hundreds of detection rules already mapped to MITRE ATT&CK. Most of the value of week one is enabling them, not authoring them.
How XSIAM detection actually fires: XQL triggers, real-time vs scheduled, and the alert pipeline.
Every detection in Cortex XSIAM is triggered by an XQL query, either continuously against the live data stream (real-time) or on a schedule. Understanding which one your rules use changes how you scope, tune, and pay for detection work.
What can fire in XSIAM: BIOCs, ABIOCs, Analytics, IOCs, and how they compare to a traditional SIEM.
In a traditional SIEM, every alert is a correlation rule you wrote. In XSIAM, alerts come from at least five distinct detection mechanisms running in parallel. Knowing which one fired (and why) is the difference between tuning the platform and fighting it.
What Cortex XSIAM is, in plain language.
Cortex XSIAM is the AI-driven SOC platform Palo Alto Networks built to consolidate SIEM, EDR, XDR, SOAR, ASM, UEBA, and Threat Intel Management into one converged tenant. Knowing what's actually inside it is the foundation for reading any quote on this product.
Cortex XSIAM tiers, ingestion economics, and what's bundled at each level.
Cortex XSIAM is sold in three tiers (NG-SIEM, Enterprise, Premium) with a shared ingestion baseline and add-on bundles. Knowing what's included at each tier lets you spot quotes that have you paying for things twice.
Broker VM standup and tenant config: documented, not bespoke.
The day-one work of a Cortex XSIAM rollout, deploying a Broker VM, registering it to your tenant, configuring NTP, network, and SSH, is published step-by-step in Palo Alto Networks docs. It is a runbook task with hard requirements, not custom engineering.
Cortex AgentiX ships 1,300+ playbooks. You're paying to author the gaps, not the catalog.
Cortex AgentiX (the next generation of XSOAR, embedded in XSIAM) ships more than 1,300 playbooks and 1,000+ integrations. Most incident response workflows already have a working template. The work is tailoring the gaps, not authoring from scratch.
How AgentiX playbooks are actually triggered: automation rules, jobs, and the WHEN/IF/THEN model.
In Cortex XSIAM, a playbook does not run by itself. Three things trigger it: automation rules (issue-driven), jobs (time or feed-driven), or a manual run. Understanding the trigger layer is the difference between automation that ships and automation that sits in a folder.
Reading an XSIAM services SOW: what's runbook, what's engineering, what's Premium Success.
A typical XSIAM deployment SOW combines documented runbook work, real engineering, and Palo Alto Networks Premium Success services. Knowing which is which lets you negotiate each line on its own merits.
When to bring a partner in: a decision matrix for Cortex XSIAM work.
Most XSIAM work splits cleanly into three buckets: do it yourself with the runbook, workshop with a partner and run it yourself, or pay a partner for full delivery. Here is the decision matrix.
See it in your own quote.
Run a check and the engine will cite the lessons relevant to every line it flags. The pattern, the dollar consequence, and the script.
Have Clarify read your SOW