Go-Live Was the Milestone. Now Comes the Part That Decides Whether It Worked.

Go-live is a milestone in the platform's life, not the end of the work

A deployment project has a shape everyone likes. A scope, a build, a cutover, and a date after which the standup comes off the calendar. That shape belongs to the project. The platform outlasts it, and the morning after cutover it begins a working life measured in shift handovers, staff turnover, and log sources that were unknown at kickoff.

Palo Alto Networks builds and maintains Cortex XSIAM for every customer at once, which is the only way a platform of this class can be built. Its Analytics BIOCs are the clearest expression of that: Palo Alto authors and maintains them, and they raise an issue, the platform's term for a detection that has fired, where behavior departs from a baseline the engine builds out of your own telemetry over time. What sits outside them is local. Which of your log sources is trustworthy. Which issues your tier one analysts can act on at two in the morning. Which sequence through the claims application your own team wrote should never appear at all. Turning that knowledge into rules of your own, tuned exclusions and a working shift is separate work from the deployment.

The failure mode here is quiet, because the platform keeps working throughout. The engineers who made the configuration choices move to the next build, and around month nine somebody asks what the line item bought. On the three engagements described below, the answer available at that point was a capable platform with parts of it still being put to work. That answer is defensible the first time and hard to give twice.

The deployment was scoped correctly. A build that tries to absorb the operating model as well runs past its own end date, and the operating model gets built badly in the bargain. Treat what follows go-live as its own work, with its own owner and its own budget line.

Four categories of work open the week after go-live, and the deployment plan has a line for one of them.

The four categories of work that arrive after cutover

Three Cortex XSIAM deployments, taken through post-deployment optimization by CWS. Different verticals, different sizes, different levels of in-house maturity. The same four categories of work opened up after go-live in each.

A deployment closes when the platform runs, which is what a deployment is for. The four categories that open afterward are all descriptions of your estate and your operation, and they get written locally to outlast the people who write them.

Only the first of the four touches the platform. The other three describe your organization, and they close when somebody inside it does the describing. Read them as a work plan in four lines, each with a natural owner.

• Data onboarding stops at the agreed scope, which is how a deployment scope is meant to work. What remains is a deferred list, and each entry on it needs a broker or a collector, a parsing check so the fields land where the data model expects them, an owner and a date before it counts as connected.
• Detection content at go-live is a starting position by design. Analytics BIOCs get more accurate as more of the estate reaches them, and the rules that describe your own systems get written afterward, in XQL, the Cortex Query Language, against real volume and real datasets.
• The operating model was the thinnest part of what existed at go-live. An organization with a running SOC brought its own and adapted it. One standing up a security function for the first time had a platform, a rota, and a gap between the two.
• Continuity of people. Analysts who sat through the build move teams or move employers, and the reasoning behind a configuration choice stays in the estate only where somebody wrote it down.

The order the remaining work goes in

Post-deployment work has an order to it. Take a stage out of turn and you come back to it later with more configuration in the way, and the two quarters in between produce work that has to be unpicked before it can be built on.

Post-deployment sequencing, operating cadence and record keeping are CWS practice views, held as opinion. Here is the sequence, with what each stage is actually negotiating.

• Tune first, and tune against cases. The platform groups related issues into a case by causality and scores the case for urgency, so a case that reads as noise is sometimes one noisy issue repeated inside a chain that is otherwise correct. Tuning is a negotiation between what the logic treats as interesting and what an analyst can absorb in a shift, and finding that line takes real volume across real working days. Calling it a cleanup exercise does damage to the people doing it.
• Extend coverage next. Each deferred source has an owner in another team, a change window, a parsing quirk that has to be resolved before anything queries cleanly, and a negotiation about whose budget covers the effort. Onboarding is scheduling and diplomacy at least as much as engineering.
• Build content around your own business: the systems it runs on, the service accounts nobody documented, the transaction sequences that should never appear. Those sit outside any generic threat model, so they arrive as correlation rules your team writes and owns. This is the stage that slips, because the platform looks healthy the whole time it is outstanding.
• Automate only where the triage step underneath has stopped moving. Automating a process that still changes every month doubles the maintenance, and the automation is the harder half to change.
• Report last, and expect to be asked first. Someone will build a slide about the platform for a leadership meeting with or without help. Settle early on the recurring measures and who assembles them.

The operating model that has to exist around the platform

A platform of this class assumes an operating model around it, as every platform in the category does. The ownership, the cadence and the institutional memory come from the organization. Build that half deliberately, or whoever is on shift will improvise it.

Cadence runs heavy at the start and lighter later: weekly after go-live, monthly once alert volume settles, and a quarterly where the platform gets described in your own words. Protect the quarterly. That is where you find out whether the account you would give a board matches what the platform is doing.

Staff for continuity. The asset is accumulated context about one environment, and staffing from whoever happens to be free burns that context at every rotation.

Settle the destination early as well. Either your team runs the platform on the runbooks and the register, or the load sits with a partner under defined outcomes. Write the arrangement down in one sentence, because that sentence is what gets read in the budget review.

Four artifacts carry most of the weight. They are dull to produce, and they are what remains when the analyst who knew everything leaves in month seven.

• A data source register listing every source, the broker or collector it arrives through, its owner, and what the organization relies on it for.
• A catalog of the rules your team wrote, IOC, BIOC and correlation alike, with a rationale against each entry, so the next engineer understands why a rule exists before changing it. Record the tuning exclusions the same way, with the same rationale line.
• Runbooks for the response paths your team uses. The policy document describes a different set.
• A standing report with a named recipient and a fixed date.

A resignation takes the reasoning with it, unless someone wrote it down.

The answer to the value question

The question you will be asked is whether the platform earned its line item, and the instinct is to answer with volume: sources ingested, alerts processed, uptime. Those numbers describe the platform, and the platform was doing its job the whole time. What the person asking wants is a change in what your security function can do.

The answer that holds up is narrower than a dashboard and specific enough to check. It has the shape of a sentence like this one: an alert from one named system used to reach a human in an hour and now reaches one in minutes, and the tuning record shows the week that changed. Or this one: two response paths that lived in one person's memory are written down, and somebody else has since run both. Those are the form a good answer takes, and both sentences above are constructions written to show the form.

The post-deployment work looked more alike across the three deployments than the organizations did. The sequence transfers. The context does not, so it gets built locally and written down to outlast the people who built it. That is the work CWS does after a deployment closes.

Go-live put the platform in place. What happens in the year after decides whether anyone in the organization can say, in one sentence, what changed.