The SIEM Was Replaced. The Way the Team Works Was Not.

What the migration plan was scoped to do

A platform migration has a shape a program manager can hold. Log sources re-onboarded through collectors and a Broker VM, detection content rebuilt from Marketplace packs and from rules written locally, analysts trained on the console, a cutover window, a rollback path held in reserve. Every line is technical and every line closes. On the engagements CWS has delivered, the plan did what it was written to do.

Palo Alto Networks builds Cortex XSIAM for a scale and speed of security operation that arrived after the previous generation of tooling was designed, and across three deployments it delivered that. Your escalation path, your handover ritual and the ranking your tier one analysts apply to a queue at four on a Friday live in the team, and a team is not something a migration plan can cut over.

So a scope gap opens between two pieces of work that both had to happen. Widening a migration to absorb how analysts work would hand a program with a fixed date responsibility for something that has no cutover. The working practice belongs beside the migration, on its own line, with its own owner and its own date.

Ask a tier one analyst which case they open first on a busy shift and you get a confident answer, held entirely in the person answering.

The Monday after cutover

Sit with a shift in the first weeks and the console is new while the behavior is inherited. Cortex XSIAM stitches related issues, the detections it raises, into cases by causality and scores each case for urgency, so the thing an analyst opens is a case the platform has already assembled and scored. The analyst re-sorts it anyway, into the order the old console produced by default, because that is the order their judgment was built on. They skim past a class of alert that was noisy in the previous platform and has been quiet since the migration. They escalate to a person, by name, over chat, because that is who answered last time.

That is accumulated judgment about one specific estate, and it was earned. Most of it was correct in the estate where it formed, and some of it stopped being correct at cutover. Which parts is a question for the people holding the judgment, since that is where it lives. The habits that survive a migration are the ones held in the team, and reviewing one against a new estate starts with writing it down.

Each of the carryovers below is anchored to something the new platform does differently, which is what makes it worth looking for on purpose.

• Queue order by habit. Saved views, sort defaults and the mental ranking of alert types came from the previous console. A different grouping and scoring model changes what belongs at the top, and re-deriving it is a task somebody has to be given.
• Alert classes quietly written off. An experienced team learns which alerts to move past quickly, and that learning was built on the old content and the old thresholds. It crosses the cutover intact while the content underneath it was rebuilt.
• Escalation by relationship. Who gets called at two in the morning is a name and a phone number held in the memory of whoever is on shift. It works until that person moves teams.
• Handover as conversation. A shift summary that lives in a verbal exchange, or in a chat channel nobody searches, is gone by the time somebody needs to reconstruct the decision three weeks later.
• Closure with no shared definition. What closed means varies by analyst, and the variation stays invisible until somebody starts counting.

The work that sits between the platform and the people

CWS has taken three Cortex XSIAM deployments through post-deployment work, and analyst working practice was the part with the least written down when each migration was accepted. Other post-go-live work runs alongside it with its own sequence. This part is smaller than any of it, and the analysts feel the change quickly, which is worth weighing when you decide what to schedule first.

Treating analyst working practice as its own line item after a platform migration is a CWS position, and the sequencing argument that goes with it is too. What follows is a short set of decisions a security leader makes and then records. The decisions themselves are ordinary. The recording is the half that gets skipped, and it is the half that survives a resignation.

• Re-derive triage order against the way the new platform groups, scores and de-duplicates, and put a review date on it while the volume is still settling.
• Write escalation as roles with hours and a named backup for each, so the path holds when the person everyone calls is on leave.
• Make handover an artifact with fixed fields: what is open, what was decided and why, what the next shift should watch.
• Agree what closed means, and what evidence has to be attached before an analyst can use it.
• Decide who may change a saved view, a filter or a threshold, and where that change gets recorded. In the weeks when everyone is still adjusting, a change takes a minute and the record of it takes longer, which is how the record gets skipped.

An operating model held in three people's heads works well until one of them takes a holiday.

What a runbook has to say now that it did not before

Open a runbook written for the platform you have just left and much of it is navigation. Where to click, which console holds the second data set, how to pull the export for the ticket. Migrate, and every one of those steps points at a console the team has closed. The instinct is to rewrite the clicks, and the clicks are the cheap half.

What changes underneath is which decisions the analyst still has to make. When causality stitching, enrichment and the second data source land together, the step that used to read check the identity system for recent password changes has been answered before the analyst opened the case. The runbook now has to say what to do with that answer and at what point it changes the response. Steps that were tasks have become inputs, and a runbook that still presents them as tasks trains analysts to redo work the platform already did.

So a rewrite is a rethink, and the new version has to state things the old one had no reason to.

• What the platform already did before the case reached a human, stated plainly, so the analyst knows what is done and what is still theirs.
• The decision points that are left, each with the condition that changes the answer. If the account authenticated from a second country within the hour, treat it as a confirmed compromise and escalate.
• The provenance of the enrichment. An analyst who does not know where a field came from will either over-trust it or ignore it, and both are expensive.
• What to do when the automated portion did not run. That happens, and the written answer for it is what stops a shift improvising one.
• Where human judgment sits, so an analyst knows which part of the case is theirs to call and which part they are reading as evidence.

A runbook that only tells an analyst where to click is describing a building the team has moved out of.

Whose line item this is

The reason this work waits is structural. The migration had a budget, a sponsor and an end date. The working practice work becomes due in the week after everyone has been thanked, when the budget has closed, the sponsor has moved on and the date has passed. It surfaces later as an odd result: leadership recognizes the old operating rhythm on a new platform, because the ranking the old console taught is still the ranking the queue is worked to and the escalation still runs through the same two people.

A migration is a technical program and it is properly scoped as one. The part that describes how your analysts work belongs inside your organization, because it describes your organization: your people, your hours, your escalation names. It gets written there, by the people it describes.

Three engagements in, the practical version is short. Name the owner before cutover, while the project still has a chair. Book the review for the weeks after go-live, when there is enough real volume to argue with and before anyone has settled. Then treat the runbooks, the handover format and the escalation roster as the deliverables they are, each with a name and a date against it.

The migration answered the question it was asked. The question about how the team works is a separate one, and it gets answered by the people who own the team.